Hi,
there are some good news from the parallel front. I have replaced
the semaphores that control the fork() and join() off threads by a
new,
busy-wait based, mechanism.
That has reduced the fork() and join() times
considerably: from the
Dear Juergen,
Very exciting! I think being able to take advantage of multiple processors
is what will make the difference for APL.
Thanks!
Blake
On Fri, Sep 12, 2014 at 5:17 AM, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:
> Hi,
>
> there are some good news from the parallel fr
Greetings,
When I tried to use File / Open on an existing APL function I got:
(aplwrap:28993): Gtk-CRITICAL **: gtk_text_buffer_emit_insert: assertion
'g_utf8_validate (text, len, NULL)' failed
Segmentation fault aplwrap
Thanks.
Blake
Greetings,
If I type a line, before I hit enter I can backspace or arrow around the
line to edit it. This is very convenient when you type in a long line and
realize you made a typo somewhere in the middle. You are able to correct
the problem without retyping the rest of the line.
Unfortunately
Greetings,
I was in the middle of editing a function using the regular del-editor, I
copied and pasted a line, I then exited aplwrap by clicking on the x in the
upper left hand corner of the screen without closing the function I was
editing. Aplwrap gave me:
(aplwrap:29325): Gtk-CRITICAL **: gtk
What version of GTK are you using? I'm running 3.10.9 though in
configure.ac I'm only checking for versions >= 3.0.12. There may be
some incompatibility.
On 09/12/14 08:39, Blake McBride wrote:
Greetings,
I was in the middle of editing a function using the regular
del-editor, I copied and
Looks like I am running 3.8.7
On Fri, Sep 12, 2014 at 8:25 AM, Chris Moller wrote:
> What version of GTK are you using? I'm running 3.10.9 though in
> configure.ac I'm only checking for versions >= 3.0.12. There may be some
> incompatibility.
>
>
>
> On 09/12/14 08:39, Blake McBride wrote:
>
Can you try putting in a newer version? 3.8.7 is from November of last
year. They've done a lot of bug-fixing since then and it would be good
to know if the bug is on my end or in GTK.
On 09/12/14 09:40, Blake McBride wrote:
Looks like I am running 3.8.7
On Fri, Sep 12, 2014 at 8:25 AM,
I am using vanilla LinuxMint 16. GTK comes with it. Upgrading to test is
sort of a big job that messes up auto-update. Let me see if I can get an
exact sequence to duplicate the problem instead. Is that okay?
On Fri, Sep 12, 2014 at 8:49 AM, Chris Moller wrote:
> Can you try putting in a ne
I noticed that last night.
The GTK+ framework preserves text attributes during copy and paste.
Since the transcript text is not editable, neither is a pasted copy of
some selection of that text.
I'll see whether I can figure out how to override that behavior.
Meanwhile, you can use aplwrap's "co
Here are the steps that reproduce the problem:
1. Execute aplwrap
2. Type the following:
∇test
[1] abc
[2]
3. Highlight and COPY (^C) the 'abc'
4. Click on the end of the [2] line
5. PASTE (^V) the 'abc' (has no quotes)
6. Hit the backspace key 3 times
7. Hit the X in t
Interestingly, the error shows on the console, and the aplwrap window
disappears BUT the aplwrap process is still running.
On Fri, Sep 12, 2014 at 10:47 AM, Blake McBride wrote:
> Here are the steps that reproduce the problem:
>
> 1. Execute aplwrap
>
> 2. Type the following:
>
>
I sent Chris a patch for this issue.
On Fri, 2014-09-12 at 07:51 -0700, David B. Lamkins wrote:
> I noticed that last night.
>
> The GTK+ framework preserves text attributes during copy and paste.
> Since the transcript text is not editable, neither is a pasted copy of
> some selection of that te
No, I don't get get a failure, but as you pointed out in an earlier
post, the copied 'abc' is uneditable--and I just saw that David has
fixed that. I'll have that patch up in a couple of minutes.
Chris
On 09/12/14 11:47, Blake McBride wrote:
Here are the steps that reproduce the problem:
1.
I just applied that patch and pushed it to github. Blake, can you try
it and see if you still get errors?
Thx
On 09/12/14 12:20, David B. Lamkins wrote:
I sent Chris a patch for this issue.
On Fri, 2014-09-12 at 07:51 -0700, David B. Lamkins wrote:
I noticed that last night.
The GTK+ fram
The backspaces I use don't work, but attempting it causes the problem. I
am at git commit 5352f834aba8f8620dcbb4ab1aab3bb64aede4a4
Do you get the error there?
Thanks.
Blake
On Fri, Sep 12, 2014 at 11:24 AM, Chris Moller
wrote:
> No, I don't get get a failure, but as you pointed out in an e
To be clear: this patch is for the copy/paste behavior.
There's still the crash on exit; I'll write about that in the other
thread.
On Fri, 2014-09-12 at 12:27 -0400, Chris Moller wrote:
> I just applied that patch and pushed it to github. Blake, can you try
> it and see if you still get errors?
Dear David,
I am using the latest git on aplwrap but the backspace on paste still
doesn't work for me.
Glad to hear someone else is getting the crash error.
Thanks.
Blake
On Fri, Sep 12, 2014 at 11:38 AM, David B. Lamkins
wrote:
> To be clear: this patch is for the copy/paste behavior.
>
> T
I reached similar conclusions. It seems that copy/paste tickles this
bug.
Copy, then paste, then evaluate, then click the close box: this is
enough to give me GTK+ errors and even stack dumps.
These are probably the important clues:
GLib-GObject-WARNING **: invalid unclassed pointer in cast to
'
FWIW: commenting out the gtk_text_view_scroll_to_mark() call in
scroll_to_cursor() does not affect the crash that I'm seeing (which is
different in its details from the crash that Blake reported). I still
get a memory corruption report, though...
On Fri, 2014-09-12 at 09:46 -0700, David B. Lamkins
It all works fine here:
Fedora release 20 (Heisenbug)
kernel 3.14.5-200.fc20.x86_64 #1 SMP GNU/Linux
gtk3-3.10.9-1.fc20.x86_64
On 09/12/14 12:43, Blake McBride wrote:
Dear David,
I am using the latest git on aplwrap but the backspace on paste still
doesn't work for me.
Glad to hear someo
Can you run it under valgrind? That should find memory problems.
On 09/12/14 12:51, David B. Lamkins wrote:
FWIW: commenting out the gtk_text_view_scroll_to_mark() call in
scroll_to_cursor() does not affect the crash that I'm seeing (which is
different in its details from the crash that Blake
I just did a pull and recompile. The copy/paste works as expected.
Hmmm... thinking... looking at the code...
I'll bet you have a lock key (shift lock? num lock?) engaged.
I'll have to go through and mask those out. Sorry...
Might not get to this until tonight...
On Fri, 2014-09-12 at 12:5
Good idea. I'll give that a try tonight.
On Fri, 2014-09-12 at 12:55 -0400, Chris Moller wrote:
> Can you run it under valgrind? That should find memory problems.
>
>
> On 09/12/14 12:51, David B. Lamkins wrote:
>
> > FWIW: commenting out the gtk_text_view_scroll_to_mark() call in
> > scroll_t
I believe I've found the cause of this problem.
There's something special (I don't know what) about the exit behavior of
GTK+ in the case that there's something on the application's clipboard.
With nothing on the clipboard, application exit was fine. With something
on the clipboard, aplwrap's apl
Thanks a lot, David!!
Blake
On Fri, Sep 12, 2014 at 2:04 PM, David B. Lamkins
wrote:
> I believe I've found the cause of this problem.
>
> There's something special (I don't know what) about the exit behavior of
> GTK+ in the case that there's something on the application's clipboard.
> With no
I just applied and pushed David's patch, the question remaining why it
showed up only in some environments and not others.
On 09/12/14 15:04, David B. Lamkins wrote:
I believe I've found the cause of this problem.
There's something special (I don't know what) about the exit behavior of
GTK+ in
My supposition about the lock key(s) turned out to be correct. I was
able to reproduce Blake's issue by engaging Caps Lock.
Chris, I'll send you a patch.
On Fri, 2014-09-12 at 10:00 -0700, David B. Lamkins wrote:
> I just did a pull and recompile. The copy/paste works as expected.
>
>
>
> Hmmm
Works for me now without errors. Thanks to all!!
On Fri, Sep 12, 2014 at 2:30 PM, Chris Moller wrote:
> I just applied and pushed David's patch, the question remaining why it
> showed up only in some environments and not others.
>
>
> On 09/12/14 15:04, David B. Lamkins wrote:
>
> I believe I'
Greetings,
Create a function like this:
∇test[⎕]∇
∇
[0] test
[1] abc
[2] def
[3] ghi
∇
Then type:
45
45
55
55
∇test[⎕]∇
[displays function]
So, the last thing you typed was the _single_ line to display the function.
If you hit the up-arrow key you woul
This package has been updated with bug fixes and additional functionality.
Thanks.
Blake
On Fri, May 30, 2014 at 8:35 PM, Blake McBride wrote:
> An APL Editor for GNU APL
>
>
> This package is located at:
> https://github.com/blakemcbride
>
> This package provides an editor, written in APL, fo
Updated once again with corrected instructions and ability to erase itself.
On Fri, Sep 12, 2014 at 3:31 PM, Blake McBride wrote:
> This package has been updated with bug fixes and additional functionality.
>
> Thanks.
>
> Blake
>
>
> On Fri, May 30, 2014 at 8:35 PM, Blake McBride
> wrote:
>
>>
I suspect it might have something to do with timing.
The window's "destroy" signal invokes aplwrap_quit(), which then
terminates the APL process.
The termination of the APL process invokes (due to the
g_child_watch_add() call) apl_exit(), which then tries to terminate the
APL process.
I suspect
Cool. Thanks for the report.
I rarely invoke aplwrap from a shell window (I usually use GNOME's
Alt-F2 launcher), so I tend to miss chatter sent to the terminal.
On Fri, 2014-09-12 at 15:18 -0500, Blake McBride wrote:
> Works for me now without errors. Thanks to all!!
>
> On Fri, Sep 12, 2014
Dear Chris,
File / Open brings up a list of functions I can edit. I select the
function and click OK. The system segfaults and exits immediately upon
clicking the OK button.
Interestingly, I noticed that it allows editing of some functions but not
others. It is very consistent, so it is someth
When you bring up File / Open, aplwrap displays a list of functions. The
first one appears auto-selected, but if you click OK you find it wasn't.
If you click on it first and then click okay, it works. The point is it
appears selected but it isn't. When you do actually select it, there is no
vi
The bottom of my aplwrap screen displays:
#0 ∆e: 1.18 ∆u: 0.00 ∆s: 0.00 ∆v: 52,043,776 ∆r: 3,239,936 ∆f: 983 ∆F: 0
∆b: 0.00 ∆rc: 37,908 ∆wc: 134 ∆rb: 0 ∆wb: 0 ∆ic: 29 ∆oc: 12 ∆cw: 0
This is getting kind of crazy. My suggestion is this - get rid of that
display entirely. Add a Help / Info menu
Greetings,
Let's say you create a large APL function using File / New. If just one
line has an open quote that isn't closed, you lose all of your work. I
think aplwrap should test the result of ⎕FX before it exits. If ⎕FX fails,
display the line number with the error and remain in the editor so
Actually, saving shouldn't close the window in any event. I'll poke at
it. Right now, I'm looking at the open-function problem.
On 09/12/14 18:46, Blake McBride wrote:
Greetings,
Let's say you create a large APL function using File / New. If just
one line has an open quote that isn't closed
I just pushed a patch I think might fix this. Let me know how it goes..
cm
On 09/12/14 17:24, Blake McBride wrote:
When you bring up File / Open, aplwrap displays a list of functions.
The first one appears auto-selected, but if you click OK you find it
wasn't. If you click on it first and
I find the APL process stats to be useful in gauging performance issues
related to time, I/O and memory (see APL_STATUS_LINE.md for a key to the
fields).
I can see your point, though: the status line does look "busy" and it
eats up a line or two of vertical space.
Putting this display in its own
It's easy enough to put the same thing in an info dialogue under Help.
I'll stuff that in tonight or tomorrow but keep the status line switchable.
On 09/12/14 20:30, David B. Lamkins wrote:
I find the APL process stats to be useful in gauging performance issues
related to time, I/O and memory (
Thanks, Chris. Much appreciated.
On Sep 12, 2014 6:07 PM, "Chris Moller" wrote:
> It's easy enough to put the same thing in an info dialogue under Help.
> I'll stuff that in tonight or tomorrow but keep the status line switchable.
>
>
> On 09/12/14 20:30, David B. Lamkins wrote:
>
> I find the A
Gentle people,
As of SVN 470, ⍞ references are taking their input from the APL source
file instead of the terminal if there is any source file left to be
read. It appears that the interpreter is starting to execute code
before the interpreter has completely consumed the source file and is
File>>Settings now has a toggle to turn the status line on and off.
I'll add the info pop-up tomorrow and, if I'm feeling enthusiastic, I'll
stick in a ~/.aplwrap to retain the states.
On 09/12/14 21:09, David Lamkins wrote:
Thanks, Chris. Much appreciated.
On Sep 12, 2014 6:07 PM, "Chris Mol
I like it. From an implementation viewpoint, that seems cleaner than
what I was trying to do with the command-line option.
Thanks. :)
On Fri, 2014-09-12 at 22:44 -0400, Chris Moller wrote:
> File>>Settings now has a toggle to turn the status line on and off.
> I'll add the info pop-up tomorrow an
46 matches
Mail list logo
