Hello Chris,
remark
I am still puzzled - or better I have no clue
-- The intermediate output is being written to the terminal by stdout /
stderr.
-- within an apl session I can scroll back and forth. The additional
lines from the above mentioned output
might interfere with with
Yeah, I've noticed that APL gets unhappy when stdout/stderr interferes
with its pty. I tried to pull down a trial version of slickedit just to
see what was going on, but stopped when it asked me for a credit card on
which to charge 300USD, so I'm only guessing that the output you're
seeing is
Hi Chris,
it' a stubborn case (the latest version).
I have an other case that fails (vs is script starting slickedit) :
apl ... session:
'libedif2.so' ⎕fx 'edif2'
edif2
'vs' edif2 ''
/var/run/user/2000/21616/.apl ### output from scrip vs
### output from slic
Hi, Hans-Peter,
Something occurred to me last night...
When edif2 starts, it fork()s but instead of exec()ing it just goes into
an inotify() read loop, That leaves two APL processes running and when
they're killed they both call the edif2 close_fun(). Among other
things, close_fun() frees v
YES - Thank You -
I'll have a good night sleep now:-)
Peter
Am 20.08.2018 um 21:17 schrieb Chris Moller:
> Aha! That both versions, edif and edif2, fail the same was a great
> clue! Another patch just committed...
>
>
> On 20/08/18 13:03, Hans-Peter Sorge wrote:
>>
>> Hello Chris,
>>
>> The s
Aha! That both versions, edif and edif2, fail the same was a great
clue! Another patch just committed...
On 20/08/18 13:03, Hans-Peter Sorge wrote:
Hello Chris,
The session blocking was my fault. Sorry for having you mislead on this.
I used
'libedif.so' ⎕fx 'edif2'
instead of
'libedif2
Hello Chris,
The session blocking was my fault. Sorry for having you mislead on this.
I used
'libedif.so' ⎕fx 'edif2'
instead of
'libedif2.so' ⎕fx 'edif2'
--
However, the latest version still segfaults on
'libedif2.so' ⎕fx 'edif2'
'libedif2.so' ⎕fx 'edif2'
)off
and
'libedif.so' ⎕fx 'edif2'
Yet another bugfix committed to https://github.com/ChrisMoller/edif.git
Mostly, what it does is detect multiple ⎕fx invocations of libedif2.so
and short-circuits them, leaving the inotify() process intact and the
message queue opened only once. It also detects )clear and
closes/unlinks the qu
Yeah, all of that makes sense--unless they're explicitly unlinked, named
POSIX message queues remain in existence as long as any process
continues to exist that opened them, and clearing a workspace doesn't
terminate the APL process. I'll have to look into what notification, if
any, native func
Hello Chris,
The session stays blocked - what ever I try fiddling around.
During this fiddling I came across on other situation that makes the
edif2 case even more interesting:
(EDIF2 is a work space having edif2 as function only)
The first session (eg. after reboot) has a double free corrupti
Hi, Hans-Peter,
That quirk where you quad-fx edif2 twice...
When edif2 starts, it fork()s a process to watch for changes in the
working-file copies of the functions passed to emacs, and it also opens
a POSIX message queue so the monitor process can communicate changes to
APL. When you quad-f
Hi, Hans-Peter,
I'm still trying to figure things out. At least I think I understand
the double-free problem and, thinking about it, that may be a clue to
the rest of it.
Chris
On 18/08/18 15:29, Hans-Peter Sorge wrote:
Hello Chris,
I have just one process running.
I recompiled and re
Hello Chris,
I have just one process running.
I recompiled and reinstalled edif to make sure it's the most recent version.
During editing with emacs:
session is blocked, then in APL session
Ctrl C
fg
'some data' ENTER - no response
in emacs: save
in APL session:
'some data' replayed
I can't make it fail, but I'll look closer in the morning.
Is there any chance you have multiple APL processes running
concurrently? Apparently, that causes problems I hadn't caught before.
Chris
On 17/08/18 17:14, Hans-Peter Sorge wrote:
Hello Chris,
edif2 blocks the apl session again.
Hello Chris,
edif2 blocks the apl session again.
edif: latest git.
apl: 1069M
Best Regards,
Hans-Peter
Am 16.08.2018 um 21:31 schrieb Chris Moller:
>
> Not that I expected otherwise, but edif and edif2 still work as expected.
>
> cm
>
>
> On 16/08/18 15:14, Juergen Sauermann wrote:
>> Hi Ha
Hi Jürgen,
is fixed - thank You.
Best Regards,
Hans-Peter
Am 16.08.2018 um 21:14 schrieb Juergen Sauermann:
> Hi Hans-Peter,
>
> thanks, hopefully fixed in *SVN 1069*.
>
> Best Regards,
> /// Jürgen
>
>
> On 08/16/2018 07:29 PM, Hans-Peter Sorge wrote:
>>
>> Hello,
>>
>> The ⎕IO bug is back.
>>
Not that I expected otherwise, but edif and edif2 still work as expected.
cm
On 16/08/18 15:14, Juergen Sauermann wrote:
Hi Hans-Peter,
thanks, hopefully fixed in *SVN 1069*.
Best Regards,
/// Jürgen
On 08/16/2018 07:29 PM, Hans-Peter Sorge wrote:
Hello,
The ⎕IO bug is back.
(note: ⎕I
Hi Hans-Peter,
thanks, hopefully fixed in SVN 1069.
Best Regards,
/// Jürgen
On 08/16/2018 07:29 PM, Hans-Peter
Sorge wrote:
Hello,
The ⎕IO bug is back.
(note: ⎕IO ←→ 0 seems to be set to 0 u
I wasn't closely following the first series of posts about this bug
but, for what it's worth, I can reproduce it regardless of whether edif
or edif2 has been ⎕fx-ed. Neither edif nor edif2 do anything with ⎕io.
[0] ~tinkering/apl-natives/vis/src >apl -L startup -q $@
⎕io
1
edif2
Hello,
The ⎕IO bug is back.
(note: ⎕IO ←→ 0 seems to be set to 0 using edif2)
∇qio_test[⎕]∇
∇
[0] qio_test
[1] ⎕IO
∇
⎕IO←1
⎕IO
1
qio_test
1
⍎¨ 'qio_test' 'qio_test'
1
1
⎕IO←0
⎕IO
0
qio_test
0
⍎¨ '
I just committed a minor patch to edif, fixing a relatively low
probability bug involving a possible message queue name collision if you
have two or more APL sessions open simultaneously.
https://github.com/ChrisMoller/edif
--cm
21 matches
Mail list logo
