Connecting FluidEnter/FluidExit at run-time - anylogic

I am toying with the FluidEnter/FluidExit. So in a simple form, here is what I am trying to do:
I created in Main an empty population of agent called Terminal. For now, in Terminal, there is only a fluidEnter connected to a fluidExit (very simple)
enter image description here
Now, on startup, I want to fill this population and set up the proper connections (the terminals are ordered).
So, on startup, I call a function init(), whose body start with Terminal t = add_terminals(); (I have only one terminal for now, just toying with things)
In Main, obviously, I also have a fluidEnter and a fluidExit. I would like to connect the fluidExit of Main to the fluidEnter of the terminal t, and the fluidExit of the terminal t to the fluidEnter of Main, so code (still in init()) looks like
fluidExit.set_fluidEnter(t.fluidEnter);
t.fluidExit.set_fluidEnter(fluidEnter);
I get an exception so obviously, I am doing something wrong. Any idea?

I think the set_fluidEnter function is deprecated or just non-functional.
Instead, you should do:
fluidExit.connect(t.fluidEnter);
So just replace set_fluidEnter with connect... nothing else.
That should do the trick

I was going down the same path as you a couple of months ago. Yes... .connect() works great. It even works as a gate. If it is disconnected, then fluid stops at the exit. Once connected, fluid starts to flow again. It is very slick.

Related

MaxMSP/Arcade Button Responding Incorrectly with HI Objject

I'm linking an arcade button connected to a USB encoder with a Max patch. The button is behaving strangely. Here's what happens:
I have the button mapped to the a key. When Max is open, this functionality breaks. Even outside of Max. Even once I close Max, I need to remap the key. I'm not using MAME or anything like that; just JoytoKey for the mapping.
This issue is negated partially through use of the HIobject. Max recognizes the button and I can use it, however it's not functioning as an on/off. Rather a bang is sent on button press and release. How do I make the button work normally (send a single bang on press, and none on release)?
Here's my patch, if it helps. I don't know how useful it is without my video files:
<pre><code>
----------begin_max5_patcher----------
2245.3oc6cszbjpaEdsmpl+CTr1gB8hGYY1jJYaRVMUptvzx1ZtzPGdX6I2J
+2i3YyCoF0.M8hqbMi6FjP5b9zQe5bPvw+92+1Sluj7EMyz3Oa7Cimd524m4
opyUdlmZOwSlmB9JLJHqphlEmnwElO2TzGAowAmnBJIt3DKNhlWcUf1ydNHk
W8bZ5AZbvKQzAExxomp6j+JMllxBMLL9W+i+hgweO4WY4rveyvneymTj219n
tl3X00m7xO+S.+tJWWy7eclVqqlr3bymMLq9uw+9hvkG9NK9sCozv75Zhv9V
DhM+G.B.P1Pf+yF.Hwxl+gKn7CHzx9RajE7A83gf77T1KE4zKeKqATaQ0RrK
pfl7Z646JnOJEkD+lX.dP0NwGhJqhsnBydOIMWgFge9SM3ib7uSSGbosPKro
r+22+V82Z+Rym7OdVYKsSzrrf2ncih4zuxaJPlcFTr4APj4AQt4wBrIbsKsE
P9WrHVrdGS+jKfSU62YyL4ZnRCEnzH45bDKKegyG78rP9k+f7g1HnC.xw.d8
taHwOY4VexhOl7ow4nfeUJ5GYYm6p34TZFMNOHmkDeHhESCSJhyGPTLnJWzO
Hvxydj5g8qFacvk+lX2e19MMNzuKkZUBskOD8RP7ayODAvdkPuCeTojjBh1.
SxH1GTqJ3WDw+zRkft.WGqJCEWaWejKDa6H15AWg0.Rer9TxQZeNNy7zf3LV
KZBWwBOqY.C3cEdj4GrVChbOWqYxXpv0a.yudy0andq4vEQPIfw+DtmKyHij
IiFYPlyhF54Nkv.BpWL.O08.UVs5lr+bwqkuPUU3t.v9lKBY5C.j0B.XfqkM
4AA.dqG.bVK.f7.ON.vctoXBc4XWmh4tZ.VQU3t.vNyBv.eKzCkCya0.rhpv
1GKh+pCDg3uz.Qv1tUNYSpiCcK73Vpd5sd8zcwAbwcRxdmzSEni.R.8EAPpL
+frhPUw6lEhB7L1RFFueHGZwHG.sa1by6koqmkCtLJAOO9uID281BDrTbDx8
sPEQ+drz2rgix65p.sFHaMVoKDVuoE9vvUGruhpvcwyB7r1sDQC96nmEXvpi
NRQU3t.vnYAX.4ACvq91UopJbW.X3rTDdXKviDfQ9qlhPQU3t.vfYAXBxxy+
QBvqN3CUUgECvuFkTdaxl8lq5VuqTv16S8UwtqdmQ6tGquljdJnpCb1Brlb8
6UZEdOy8KUlRt4luoAwGSNY.rUE3qcpwwYYFs2j+XH702aSkvvox616Z67tH
fcEvNsit1hVtqsbyOv8z0Von5B8KXGQU3huoFPf28MfAon5BcFXOQ0EeKT.d
tOHa0E5Avdhp3EipDGkD8Eipkazc6NbO+xPB16ZTIWe0ONDhCAX6iJcJoZqg
Qd27dYitosF8JVqbE6.2whT1WsOGNGYgkMVP5uVf2VXazT0j.br7KOGDh4.B
1Ai4CHt98U5njDtpbNIMefVbLHOXxdnFFwN28vRMXSTexL3krjnhbJWfeuB.
9aw4oIG9mexdKH8TFz5TxGW1.TteUrHZ2VjpPc+MVbMvxKiQKOS+ZTpEC2NV
tzlDmyGgNjwGjnc66aegtZX4bQd6Fqyw1da6ZcwGZER9XVgK101FgvXyg06H
qYObAOOtIJoAJRoCZFDFU0LvQMSoVPqUyeXXOpKRC9LOYxjxdZwgltR3kmy3
7SgAQMk5XOp7ORhZz.qQkTjQOlkew7arbMnrmK+2TPnTwNmv8KK6PFMrwDpx
0U6wcWvwfy4BGLRaFFEHiGKR6lHNQBOmb4Yj3GS6vRjYnTMr7vjHdH.cVHlA
ou8h4zlPXW+ZYfEWlcMo7vfv24cN6+1d4Vf5Iw17kprA.GAh5oLgMUPQdBmO
gEJsT97fTwHKeHNKMT5PbQL6+THQAOKC13C1zzyBundVCcJyyBgttmZoqzFx
ZfgDaBafdHxnRGBGRrpuvDIbVIM9MVbmUyGuZ1rL3fmaitkCmiNkUQQVdHkO
Hec5TEpqlNUSmpoS0zoZ5zRJRvMPmBzzoZ5TMcplNUSmNlNMHH8LRApTo0SS
ipoQ0znZZTMMJTQZTcv8ZZTMMplFUSiJjFEnHMpNndMMplFUSipoQmPi1tq7
pPkd05poS0zoZ5TMc5eToSG9PNYftgmHJC8cKUSnpIT0DpZBUo6gO5F1CeMc
plNUSmpoS+CCcZaASSSX0snYYNBbbdPs5cOHpoG58BZjkTjF11sco.tdJn4Q
ZVNKt2Dlt2YOiq9xfndORTpC2t9yUk9qJ2EtU8nuYeygqqgcYHP1w9lrXDYZ
ZsBPpRQmHjS86.Y+i7qR4GnxyMIEWhr1FEChUBJcuplAbbDj0GpyRN.Gjjx1
F42cKjeemouien5zroP4uprsQ982.4GB8l91zsOxORIweLizH4WnINe5a06s
FBTm2P6ejWc1mzywBONYUVVzkNJI8HMsxQwMRWmkC.3uYjNpgsiLf5zX6sPB
.ag0Iez8AM6BoD6FhrcCYpsRnmjwLu8SDjY13tah.1VhH3reh.PhHP1OQ.JQ
D72MQvEKQDv6mHPtmrXpIBNRDAv9IBtRDA39IBxnlPagHnTfIvsKvDjRdWAm
y6PjfL.QclzQnmiUksIx+XJRIxu+LdGRDjqEZyDPdRJaajek7eXrWFikeGfb
4WjuEan7CuECVY1ObeVmlUFvMQGIJxI7VEcDYS7eyG7nhtff1.4GAgV6mDS1
BIlfq+q2wtHwaQDzHOxNhwaQLyUYY88RhcUJNDxL7f9tBRpzM7f90I4kgGUy
wHb961ww3pjEO45qQggNBxH40ZSyH0nip0s9GsMZiiRZyLyF3FNxzFT88tXz
Q0ZSyrnMTaTZt8XNKUt6LsxO4h1rMRrRtHRPyv36I3OgDMRLr+Lk1iZv+5UJ
Di+M2Z9fym+fll0HO0Jh4ofelTG.+y0GyhqOtNwEZlR+f0dI0ItPyfzv2Y4z
v1cvy7Kml79T0eYYRiKXsAeTBkkccUdXpbeEyNGTCZU4qou+MdE9+qypUK.
-----------end_max5_patcher-----------
</code></pre>
It's hard to give an exact answer without knowing what your USB device outputs, however in your patch whatever exits the [hi] object goes into the [live.text] button, which is set to Button mode, always converting it to a bang.
In the patch below I set the [live.text] button to Toggle mode. I also took the liberty of cleaning some other things up.
The next thing though is that you will need to find out what part of the output of the hi object is the information you are looking for. You can do that with a [print] object. Then you can select that number with an [unpack] and select the 1's and use that to trigger [random] (see the patch below).
----------begin_max5_patcher----------
1559.3oc6Z0ziiZCF9bxuBDmmF4O3ypdpWpZu11SqVE4P7Lw6BXpwjYFsZ+u
WaCjPBDvIgY6glLRCAaiseedd+zjusbg6F9azRWme14SNKV7skKVXZR2vhl6
W3lQdKIkTZFlaBOKilKceptOI8Moo8ew4YV9VG4NpSdU1FpvgkatKkUJUegH
cJekIS1QKc1PkuRo4N.Gh5QfsyUgfVplZhjwyWmxxoI7pbyriZFgZlY4oToY
q.aZjs0rA3a9xOAAtGGIuR1NTP6JPTa.V9KqEzDYsTiBvq.O4.AlKXXj9BBr
B37Y8y78kK0+6IKQmb5qp8QOvoPvNBYSIDwWuLfTadef5CDCgX.BFeThPFAB
MuBTUdAI4qJBT8msxUzvxEto05ljuWPqEJWCjcxEmOeYL.FFrJV+IDDFiCQd
f.EFfhWgMshiQ.LJ.hdxIL7tPjKa.jriyKo055M1.6nBps3S3Mq6hA8kRTTv
GglbIM8nA6IRDpuD4MrDgtDiugj+hlqGknQ.+AH5HCoh89HT1kNrAcQ0U4CZ
V3HCenT57a2EVx8ngQJ3.Ka21GzlYbvynUfqAJX7GCbAsDt7CuQ3B9CFt.Gz
qtC3pR41npciumHxIYz9cvjzr5w+azbpfk33372+4u537G72KkLkSWGacn.O
DIofHTKljJVSyIaRocefqya7jlmP.nu4oxAkVcqg16xzkj8zsqIRofsoRRO9
sxFjrAJ0HVZEk+bayssepvUk0rcA5MJ7vN8jgkxyeYPv+jQkoHuN3zI8UtiK
jSOEsvGptKi9R6kqT4IiVVRdg1yXqqpyTtig9ia1ziyG21P48v+7jNB75GIB
+g3kYGyVy.7UFERmv5zp4CktwPReWuaymz+Elb0qp7s4u5TjRdWuk2xJKlNS
Z73dlQvUQfy3TuXi0afwGnW703lFAFG6s1QskYFX7VG3aT3fH7co2kx1SWY.
7AbY2qyKFoa.0j3n9pId0Aj8uFzEFYi+cofjWxZQXz7vG2XVZCYfLfj+QETP
MZndmqthrHzv4j7MFdXzoYFCQLRF6.6Kw9RJxJ6HC0EFEo9uuen1qFDbLAN7
E0cGpx.z+ANFPgAyPQBOqzQTZTSY2GVmwiIkQePu7ddlKxHlAGXaXL+wr1Ay
mcsARsAN8vmKbymVqxo0VdlCDXIP6aRsLHnGPOklH16GasDHsmtS2o2.poi+
2F32hhs5ESGqgMym.e+.eHHFqMLLG9ENBzA+R47htxs9dAsP4f6rhHFOVU30
q7hmfA1JHuJ4lkv8RjhBmVqryDr2ZKdYKKQOQDw6GYK0iUTIWqU9pDzoNzkl
ZBCF.A8gpv851PHOEV6E34oc6zMmosDI47nXIorhCGBa2vXKbIaJ4opHepMx
Nin964RAe8e8J6EhHqDsJiu+PbEkaEVJ8PfmoG5WUoPVWFAeOipaoy.ZnuJP
jNKe+Pbm9NSqvHD7bohlVWpXJ5g.xcjktLV2hKpCjySaTWOhUlNDMyV+dR3o
Jmn7ssbMQ7xlSmzpb1+T0z8oOqxXkJJNzSaGMgeasDmfJXF7UeKUUX9nTwzC
0JpHvSqc4G8fJFkJf1SEvakJhBLTQ7CpXPpfPDE3oogKMLqn.jef18K3AEbQ
J.YGEbyNj7hMT.7AEbQJ.ZGEbyNhv.sin.zCJXPJnM8GKngwFpcwDPFqA7Cp
XzjVcv1m0pyMGcvGqq5Iv6AYLZtRX6yU5lohvProNo+eQEMMdxY4YlBW8Auc
1O5FSgl51Osn+RdkHoc607xLb5TLIsTxxOTY7mN7CHoyX3hsTgol1AOmAaW3
H0jBmXgMmHsykNQi4TDiFVDg20B6YwBi8lAI7.NM5RMGqDxh0Qe1L28BoOP2
I0OPyA1YgDglKAZRnaNT28sQWXNDIrUJ39yjI7jNKN0MUFaaAW4TswuHLdnW
bVP+WeTj+pPuabb0+9WfPvJu3A55d0Tis.EvygIQnMpp52E68uT1nr1WlpC6
QJJ1SEkMC1rFtYjuvMttidxbKKu9VyAv5Jn6YsiutEhHYGSRSZOnV22BpO.e
WcbbQdEqINfR5VpOYURYoNclxBRsfXNX8kee4+Jwi4ZG
-----------end_max5_patcher-----------

provideDebugConfigurations not getting called

I am using the vscode-mock-debug git as the basis for my work.
Activation event is OnDebug, although same result
I implement provideDebugConfigurations in my DebugConfigurationProvider and its not getting called.
provideDebugConfigurations(folder: WorkspaceFolder | undefined, token?: CancellationToken): DebugConfiguration[] {
return [...my data in here];
}
the resolveDebugConfiguration (the original from mock-debug) is called, I can set a breakpoint. However the provideDebugConfigurations is never getting reached. build 1.36 of vsce. am I missing something obvious ?
this is the answer from the vscode team: https://github.com/microsoft/vscode/issues/78362
I have investigated this and it is expected behavior.
Namely, provideDebugConfigurations is only called then the debug configurations are needed to generate a launch.jsonfile. If you click on the configure command the provideDebugConfigurations will get nicely called.
However if you do not have a launch.json and you simply press Debug Start, vscode will try to start debugging without using debug configurations, but using one on the fly provided by the resolveDebugConfiguration call.
More about this can be found in our docs https://code.visualstudio.com/api/extension-guides/debugger-extension
Thus closing this as designed.

Openpanel and symbol communication not working

I am trying to make a patch that plays audio when a bang is pressed. I have put a symbol so that I don't need to keep reimporting the file. However it works sometimes but not all the time.
A warning in the Pd console reads: Start requested with no prior open
However I have imported an audio file
Is there something that I have done wrong?
Use [trigger] to get the order-of-execution correct.
One problem is, that whenever you send a [1( to [readsf~] you must have sent an [open ...( message directly beforehand.
Even if you have just successfully opened a file, but then stopped it (with [0() or played it through (so it has been closed automatically), you have to send the filename again.
The real problem is, that your messages are out of order: you should never have a fan-out (that is: connecting a message outlet to multiple inlets), as this will create undefined behavior.
Use [trigger] to get the order-of-execution correct.
(Mastering [trigger] is probably the single most important step in learning to program Pd)

In Pure Data is there any way to track down a "signal outlet connect to nonsignal inlet (ignored)" error?

I have a Pd patch which calls in a second patch as an abstraction.
The second patch works fine by itself. But when I try to use it from inside the first, I'm seeing this
signal outlet connect to nonsignal inlet (ignored)
error. But I can't see WHERE it's happening.
Doing "Find last error" just gives me.
... sorry, I couldn't find the source of that error.
How can I find out which two objects Pd is referring to with that outlet / inlet?
(The outlets of the subpatches are being wired into [dac~] in the main patch)
These subpatches USED TO work, until I tried to add Open Sound Control to them with udpreceive. And, like I say, they still do work, accepting the OSC if I run them on their own.
actually, Pd (>=0.43) became quite good at locating the source of errors, but unfortunately this is little known (and less documented).
if you get a findable error (usually those in red; and the error you get is one of them!), you can click on the error-line and it will take you to the object that complained (and select it)
the actual click-sequence is OS-dependent:
linux: Ctrl+LeftMouseButton
w32 : Ctrl+LeftMouseButton
OSX : ⌘+LeftMouseButton
alternatively you can get to the error, by clicking on the error-message and then hitting
Return
(Enter should work as well).

Perl CGI gets parameters from a different request to the current URL

This is a weird one. :)
I have a script running under Apache 1.3, with Apache::PerlRun option of mod_perl. It uses the standard CGI.pm module. It's a regularly accessed script on a busy server, accessed over https.
The URL is typically something like...
/script.pl?action=edit&id=47049
Which is then brought into Perl the usual way...
my $action = $cgi->param("action");
my $id = $cgi->param("id");
This has been working successfully for a couple of years. However we started getting support requests this week from our customers who were accessing this script and getting blank pages. We already had a line like the following that put the current URL into a form we use for customers to report an issue about a page...
$cgi->url(-query => 1);
And when we view source of the page, the result of that command is the same URL, but with an entirely different query string.
/script.pl?action=login&user=foo&password=bar
A query string that we recognise as being from a totally different script elsewhere on our system.
However crazy it sounds, it seems that when users are accessing a URL with a query string, the query string that the script is seeing is one from a previous request on another script. Of course the script can't handle that action and outputs nothing.
We have some automated test scripts running to see how often this happens, and it's not every time. To throw some extra confusion into the mix, after an Apache restart, the problem seems to initially disappear completely only to come back later. So whatever is causing it is somehow relieved by a restart, but we can't see how Apache can possibly take the request from one user and mix it up with another.
This, it appears, is an interesting combination of Apache 1.3, mod_perl 1.31, CGI.pm and Apache::GTopLimit.
A bug was logged against CGI.pm in May last year: RT #57184
Which also references CGI.pm params not being cleared?
CGI.pm registers a cleanup handler in order to cleanup all of it's cache.... (line 360)
$r->register_cleanup(\&CGI::_reset_globals);
Apache::GTopLimit (like Apache::SizeLimit mentioned in the bug report) also has a handler like this:
$r->post_connection(\&exit_if_too_big) if $r->is_main;
In pre mod_perl 1.31, post_connection and register_cleanup appears to push onto the stack, while in 1.31 it appears as if the GTopLimit one clobbers the CGI.pm entry. So if your GTopLimit function fires because the Apache process has got to large, then CGI.pm won't be cleaned up, leaving it open to returning the same parameters the next time you use it.
The solution seems to be to change line 360 of CGI.pm to;
$r->push_handlers( 'PerlCleanupHandler', \&CGI::_reset_globals);
Which explicitly pushes the handler onto the list.
Our restart of Apache temporarily resolved the problem because it reduced the size of all the processes and gave GTopLimit no reason to fire.
And we assume it has appeared over the past few weeks because we have increased the size of the Apache process either through new developments which included something that wasn't before.
All tests so far point to this being the issue, so fingers crossed it is!