lol

General APL language issues

lol

Postby Tomas Gustafsson on Thu Mar 05, 2015 3:37 am

This tells it all:

Image

:-) yep

Found it by coincidence, while pushing and panicing with the updating mechanism that an angry mob of users is waiting for.

Dyalog does a tremendous job in keeping the users settings, per namespace, so this was most certainly a user's blunder (user = Tomas, btw). Each time i've saved the workspace, the _Http.⎕USING, enlargened with whatever testing etc i've done during development, has been saved as well (my bug was that ⎕USING wasn't local in the fn, plus ⎕USING,←⊂'System.IO').

With this small dfn one can easily wander through the namespaces and look for bad footprint:

      U←UsingTest

U←0 2⍴'' 0
{
U⍪←(⊂⍕⍵),⍴⍵.⎕USING
0=⍴a←⍵.⎕NL ¯9.1:
∇¨⍵∘⍎¨a
}#
U⌿⍨←0≠U[;2]

A bit clumsy as it modifies an outsde variable... i guess (?). But then it's easy to modd, and it does the job:

      UsingTest
#._Http 822
#._Vessel.Fireboat 4

The simulator code holds 115 static namespaces, for code organisation and maintenance. A job to walk through manually! Found some non-1 ⎕WX's, and other household smudgies as well, by slightly altering the dfn.

Could mention that i carefully clean the workspace at each app shutdown, and (re)build up all settings during init (ie. i keep the ws clean - good practice!). No forgotten trash allowed in the corners, no random a b c variables hanging in namespaces (for the production code to nightmareishly rely on) :-). Zzz
Tomas Gustafsson
 
Posts: 91
Joined: Mon Sep 19, 2011 6:43 pm

Re: lol

Postby ray on Thu Mar 05, 2015 6:22 pm

Not only do I like to keep my workspaces clean, I like to keep them "virgin".

That is to say I (try) never to save a workspace after it has been run.

If I make changes during a debugging session, I will, after testing, copy the changes into a "(pseudo)Clipboard" then xload the original workspace, paste the changes from the "clipboard" and then save the results.

(I have user command tools to copy and paste APL objects "to" and "from" a pseudo-clipboard. The clipboard is in fact an external variable.)

Of course, if you don't mind running from scripts rather than workspaces, or re-building your workspace from code libraries at each run, they you can also achieve the same virgin state.
Ray Cannon
Please excuse any smelling pisstakes.
User avatar
ray
 
Posts: 192
Joined: Wed Feb 24, 2010 12:24 am
Location: Blackwater, Camberley. UK

Re: lol

Postby Tomas Gustafsson on Thu Mar 05, 2015 10:06 pm

That's so clinically clean that your workspaces totally shine! :-) Good to hear you appreciate the clarity around; i've had a feeling APL coders don't too often care too much about that.

Btw, already in Kings Quest I it said "save often, save early!" :-).

Years ago, one could to perform a )copy into a )clear ws now and then, and the ws file became a bit smaller upon )save. Apparently there was something cached, or not cleaned out. But that's no longer needed - APL is totally solid re. memory leaks and management. Following task manager on the loopy simulator is a joy. The memory consumption fluctuates somewhat, as expected, and above all stays the same once everything is loaded and gone through once, no matter how many hours it runs. Also means i can re-execute LX a hundred times with no problems (and there is huge object creation & load each time, but all data is in temporary namespaces). One thing however i've noticed IS mandatory, is a )reset each time. If i don't do that, the app will crash within 10 LX's - at least it used to bfore, so this is a habit (this could have to do with the .net middleware. In fact, the last exit function drops these lines into the session, to be executed conveniently, ie. the )reset plus one other:

)reset
LX
)save

(Sometimes i manage to stall the display driver, with a sufficient amount of uninhibited GPU shader coding - THEN i am out from APL, but i've also learned that .net seems to do a good housekeeping job; what(ever) was created in a process gets cleared out upon process exit. And Windows, from Vista on, has usually survived this, after an automatic display reset). Naturally, if you get the BSOD, you're out :-). And BSODs we can enjoy in 2015 too.
Tomas Gustafsson
 
Posts: 91
Joined: Mon Sep 19, 2011 6:43 pm

Re: lol

Postby paulmansour on Mon Mar 09, 2015 3:44 pm

I vociferously agree that )Save is extremely dangerous! And I have not performed it in many years now.

Using our code management system Acre, every change in the editor is automatically saved, and all you do is )Off. When you load up the workspace again, all the code is copied in from file. I assume you can achieve the same using Salt, etc.

I cannot recommend eliminating )save from your life strongly enough!
paulmansour
 
Posts: 375
Joined: Fri Oct 03, 2008 4:14 pm

Re: lol

Postby DanB|Dyalog on Mon Mar 09, 2015 11:33 pm

Using SALT is definitely safe and the way to go.
You can keep a version for each change of an object if you wish.
You can even Snap your ws and have the command create a program to regenerate the ws for you, ⎕LX included.

The problem with workspaces is they tend to gather "dust" that jams the gears every once in a while. Dyalog is a HUGE program that keeps on changing and that kind of behaviour is inevitable. It's not specific to Dyalog, other popular pieces of software suffer the same problem, take Windows for example.
DanB|Dyalog
 

Re: lol

Postby Tomas Gustafsson on Tue Mar 10, 2015 1:22 am

DanB|Dyalog wrote:The problem with workspaces is they tend to gather "dust" that jams the gears every once in a while. Dyalog is a HUGE program that keeps on changing and that kind of behaviour is inevitable. It's not specific to Dyalog, other popular pieces of software suffer the same problem, take Windows for example.

I wonder how SALT would work for me... might be a good solution.

The execution structure in a game is not quite "normal" though. A game basically goes into a loop right away, after sufficient pre-work. And stays in that loop until exit. There are no ⎕DQ's or such; the loop has one checkpoint where it tests if the topmost entry in an execution que has expired, in which case it executes it, in thread 0 or [new]. That execution may modify global data somewhere, spawn new functionality chains, and it probably inserts itself back into the que with a suitable delay, or inserts it's successor in the que, whereby the last successor again inserts the topmost, so the "closed chain" for that particular functionality stays alive.

In any case, everything relies on persistent, globally accessible data, which the que-called functions have handy and modify. Hence all data manipulation happens "out there", in persistent namespaces. There must always be a value for everyhing available, so the program init creates a fair amount of namespaces with defaults (in addition to quite a few .net objects).

Meaning, however, that whatever happened, must happen in reverse order upon exit. And that again means that after shutdown, everything is truly cleared out; no memory or other leaks are allowed! And by that, we are ready for )save :-).

Maybe the thinking model here enforces simplicity and straightforwardness. But invoking SALT might nevertheless be something... as long as there is nothing that slows down, or hinders from practicing the "flying on light wings" style.

Here i must also mention that the application has absolutey no global ⎕TRAP! There are ofc local :Trap's, but if the app crashes, it really goes to hell. The reason for no ⎕TRAP is that the app may not crash .. hehe, (sic). But the fact is that a game loop touches practically everything during the first few hundred cycles (few seconds). There are no "hidden surprises", and i've found it's better to not do the error trapping - this motivates to behave and code better :-). But fact is, the same goes for the middleware 3D engine; calling it wrongly crashes it brutally. It's very much a concept of intolerance and bad attitude.
Tomas Gustafsson
 
Posts: 91
Joined: Mon Sep 19, 2011 6:43 pm

Re: lol

Postby paulmansour on Tue Mar 10, 2015 1:40 pm

Tomas,

In theory there should be no reason you could not use a source code management system like Salt. You can gain all of the benefits of keeping all the code in files, eliminating the workspace as a storage device for development purposes, and still have speed at start-up by distributing a complete workspace for runtime. This is what we do. At first we tried using the same start-up routine for runtime as for developement (loading in all code to clean workspace) - but the extra time required at start-up - not that much really - annoyed the end-users.

Paul
paulmansour
 
Posts: 375
Joined: Fri Oct 03, 2008 4:14 pm


Return to Language

Who is online

Users browsing this forum: No registered users and 1 guest