Thanks! A billion would be as good as _ for me.
On 2020-11-15 22:10, Henry Rich wrote:
Thanks very much for using the beta. I am trying to trim up the
control blocks & thought that no one could ever want more than 32K
lines of typeout...
I'll set it in the next beta to allow a billion lines -
Thanks Julian and Henry,
I use very long lines (105,000) to test the string output of my svg files for
jig, so I too would like something in excess of 32k. I don't think that I would
need a billion, but 150k would be nice.
Cheers, bob
> On Nov 15, 2020, at 20:10, Henry Rich wrote:
>
> Thank
Please also do it for line width. A line can be quite long eg minified
javascript.
On Mon, Nov 16, 2020 at 12:10 PM Henry Rich wrote:
> Thanks very much for using the beta. I am trying to trim up the control
> blocks & thought that no one could ever want more than 32K lines of
> typeout...
>
>
Thanks very much for using the beta. I am trying to trim up the control
blocks & thought that no one could ever want more than 32K lines of
typeout...
I'll set it in the next beta to allow a billion lines - is that enough?
Henry Rich
On 11/15/2020 11:07 PM, Julian Fondren wrote:
On 2020-11-
On 2020-11-14 16:08, Henry Rich wrote:
I have been rewriting interfaces to make the JE reentrant. This beta
has changes in I/O to the front end, which has more ramifications than
I can test for. I am hoping the beta users will cover the
combinations & report anything that looks unusual.
I jus
It is up to qwebengine how to handle spaces. If you don't want possible
line breaking then you should use nbsp instead of space.
On Mon, Nov 16, 2020, 2:35 AM 'robert therriault' via Programming <
programm...@jsoftware.com> wrote:
> Hi Bill,
>
> I can confirm that each time that I create either a
Hi Bill,
I can confirm that each time that I create either a jig view or run a video
from a video lab that a separate QTWebEngineProcess is created.
As for the line breaks in tooltips, the issue is not so much inserting line
breaks as much as it is having line breaks inserted in the middle of
Moreover, (#:~ $)~ makes for a better smiley.
Am 15.11.20 um 19:23 schrieb Henry Rich:
> On reflection I am not going to implement (4 $. $.) in special code.
>
> The fundamental operation is 'express the numbers in y, which are
> elements of (i. #@, x), as index lists into x'. This is achieved b
On reflection I am not going to implement (4 $. $.) in special code.
The fundamental operation is 'express the numbers in y, which are
elements of (i. #@, x), as index lists into x'. This is achieved by
(#:~ $)~
y can have any shape. (4 $. $.) works only on an argument that happens
to h
There are issues with cache management which mean that sometimes
multipass solutions involving appropriately simple passes can
sometimes outperform single pass solutions.
FSMs with backtracking also get used in regular expression
implementations (which in some cases run into exponential time
issue
the aspiration of a single pass fsm solution is the speed that comes with fsm.
I understand that multipass or non-fsm solutions are simpler to write.
On Sunday, November 15, 2020, 10:02:30 a.m. EST, Raul Miller
wrote:
After taking a walk and thinking about this:
I think the right appr
After taking a walk and thinking about this:
I think the right approach for generating those empty words would be
to generate the whitespace tokens and then remove the undesired
content.
splitword4=: 0;(states'');a.=' '
1.1 2.1NB. 0. start here
1 2.2NB. 1. other
1.2
That could be done, with the introduction of four more rows in the
state table but would run into the same issue.
Do you see why?
Thanks,
--
Raul
On Sun, Nov 15, 2020 at 8:53 AM 'Pascal Jasmin' via Programming
wrote:
>
> You're almost there Raul, and I think you are much fresher on fsms than
You're almost there Raul, and I think you are much fresher on fsms than I am.
The flaw is only that an empty word should be emitted only when multiple
consecutive delimiters (2+ whitespace in your example) are encountered. The
behaviour at start and end is correct.
On Sunday, November 15, 2
Ah, I see the difficulty: there's no character after that final space
to be used to backtrack from, to emit the empty token at the end of a
string like ' this is a test '.
So the machine sets up to emit an empty token, then runs out of text
and instead emits a whitespace token.
Or... this backtra
Oops, no, it works. I was just testing on an older version of J.
Though the actual implementation of splitword2 is flawed, since it
doesn't support the idea of strings which don't begin or end with
whitespace.
Here's an implementation with almost the behavior I think you specified:
splitword3=:
Thank you Raul for the start.
I do not get an index error with your splitword2 test but the goal fsm is to
turn
'this,, is, a, test'
into
<;._1 '|this| | is| a| test'
ie. produce an empty word when consecutive delimiters are present, but don't
spit out empty words between all delimited toke
Hmm...
The basic purpose of the new backtrack mechanism is to allow token
formation rules to depend on characters which have not yet been
encountered but which will be encountered soon. It also introduces
some new risks, as a consequence -- the possibility of infinite loops
and the possibility of
I am not aware of any harm done (unlike Brutus).
On the contrary, I provided in an elegant and, apparently, efficient solution.
And that on Friday 13th.
R.E. Boss
-Original Message-
From: Programming On Behalf Of Henry
Rich
Sent: vrijdag 13 november 2020 21:38
To: programm...@jsoftwa
19 matches
Mail list logo
