Re: [sc-dev] questions about scel

[nescivi <nescivi@xxxxxxxxx>]

Hi Justin,

On Monday 28 December 2009 11:47:53 Justin Glenn Smith wrote:
> As I continue to attempt to map some of the data flow in scel, I have a few
>  questions. I should preface by saying that I accept the likelihood that
>  anything I describe as an error or problem is a misunderstanding on my
>  part - I am sharing these observations not as a critique but in the
>  process of trying to understand how scel is designed and used, in order to
>  better contribute to the project.

ok, understood.

also please understand that I'm not the original author of scel, so all my 
observations are also from what I understand how it works by looking at the 
code, and don't know the reasons for all of the stuff.
I hope Stefan Kersten, who wrote scel, is also reading this thread, so he can 
shed some light on stuff too.

> Is it the case that sc and emacs are communicating via two channels,
>  stdin/stdout of sc (via emacs standard make-process) and simultaneously
>  via a fifo? If so, why? Or is the fifo instead of the stdin/stdout route -
>  and if so, why that?

I'm not sure about this.
 
> In ScelDocument: init, initFromPath and prInitFromEmacs instance methods
>  all set the checkCurrent variable to the same anonymous function,
>  immediately before calling it. No method relies on the existing value
>  (every method that uses it sets it first) and every time it is set, it is
>  set to the same value.

ok, the checkCurrent is the same function each time, I guess that could be 
hardcoded in the *new function, although... the methods mentioned are the 
initialiation functions for the different ways a ScelDocument can be created.

in prInitFromEmacs it is called immediately after it is set.


>  Similarly there is the instance variable cFuncs
>  which is completely clobbered by the only methods that call it, other
>  methods append values to it, but never call it, and will never get called,

cFuncs is short for completion functions, and these are evaluated when the 
call to emacs is completed and the hooks in EmacsInterface are processed.
Since it's possible to execute a block of code in sclang, that sets several 
methods of ScelDocument that add to the cFuncs, before scel has actually 
created and returned the reference to the actual emacs buffer, that's why this 
stuff exists.
I guess it could be implemented cleaner now using addFunc, but these either 
did not exist when I wrote it, or I didn't know about them.

>  since the value gets clobbered before getting used in every usage case. I
>  am guessing that these are signs that the class is in kind of an
>  intermediate under construction state - or is there a logic here I am
>  missing? Neither of these instance variables exist in the Document class,
>  nor do they get called or set by any class other than ScelDocument itself.

CocoaDocument doesn't need this mechanism, since it is implement in C# 
primitive code with direct returns to the language.


>  Are they there for use by some Quark?


> Also in ScelDocument init and initFromPath directly call an EmacsDocument
>  instance's prNewFromString and prNewFromPath instance methods
>  respectively. This makes me think that these instance methods are either
>  misnamed or being misused. Or is this an sc idiom for a "friend" class?

pr as suffix is used to indicate it's a kind of primitive method, which 
shouldn't be called directly by the user.
EmacsDocument in itself should not be used directly at all.
I guess strictly speaking I shouldn't be calling them directly, and add in 
another method that does...


> If I am parsing the code for EmacsDocument properly the string, currentLine
>  currentBlock and currentWord instance methods are defined by quoted lisp
>  code, rather than calling an elisp function via a token sent to elisp -
>  title_, front, unfocusedFront, syntaxColorize, selectRange, prisEditable,
>  removeUndo, string_ and prclose use this latter method, which I think is
>  the right way to do it. This prevents sending code that has to be parsed
>  and then evaluated for each call (saving a small amount of bandwidth, a
>  small amount of cpu usage, and most importantly leaving the elisp code in
>  a place and format where it can be much more easily read and edited). The
>  EmacsBuffer and EmacsWidget classes do the same thing.

string, currentLine, currentBlock and currentWord were my careful attempts to 
make something like that stuff work somewhat, but I haven't ventured further 
down that path, not being familiar enough with emacs-lisp, or finding a 
solution for the asynchronisity problem.
I guess that's a point where I have to admit I'm educated as a physicist, not 
a computer scientist, and I'd like to make art, rather than program. :)


> EmacsInterface is being initialized twice, once by Emacs and once by
>  EmacsDocument, one immediately after the other. It could be that I am
>  missing at the moment the reason that this has to be done, do let me know
>  if I am.

I think you can't be completely sure in which order sclang is compiling all 
the class library files, and this is a way to ensure that EmacsInterface is 
compiled before either Emacs or EmacsDocument.
I guess Emacs could just call the initialisation to EmacsDocument though, 
since that one requires EmacsInterface then.

> On the elisp side of things, my one observed problem so far is that
>  sclang-post-buffer is accessed in a variety of different ways - sometimes
>  it is accessed via the constant string (ie. in sclang-start), and
>  sometimes via sclang-get-post-buffer (ie. in sclang-init-post-buffer) and
>  then everywhere else what seems to me "the right way" - through the
>  with-sclang-post-buffer macro. Actually sclang-init-post-buffer accesses
>  postbuffer via both of the latter two techniques in succession, which is
>  redundant since with-sclang-post-buffer is calling sclang-get-post-buffer
>  anyway it seems it should really be one or the other not both that are
>  used. I was playing around with making a modification where the "real"
>  postbuffer would be a hidden buffer, not accessible by normal buffer
>  selection methods, and the postbuffer shown to the user would be an
>  indirect buffer (to fix the "what happens when the user closes the
>  postbuffer" issue). I was having a number of issues, which could have been
>  caused by my misuse / misunderstanding of the emacs indirect buffer
>  feature, or could have been caused by the various ways that the postbuffer
>  is being accessed / potentially created. Or some third problem that I do
>  not understand, of course :).

hmm... can't say much about this, other than that it may have been tweaked by 
vairous authors over the years. I remember at least one patch made by Martin 
Rumori, to ensure that the post buffer would stay in the frame where it was 
already showing before the language recompile.
It may well be that a second look at this will be beneficial to remove any 
redundant and unnecessary code, while maintaining all the desired features, 
and gaining some more.

> I have attached my updated diagram that I am editing as I read through the
>  source (still very incomplete, and any inaccuracies likely reflect my
>  failure to understand the code). I am sure it would have taken less time
>  to use or put together an automatic call / access dataflow diagram than it
>  is taking to make one, but I am learning quite a bit in the process of
>  doing it by hand.

Thanks for doing this :)


> Also, who knew we had ascii slider widgets! I intend to look a bit further
>  into that, and maybe make a nice looking unicode variation (I am sure
>  there is some set of unicode symbols that could be combined to make a
>  really sweet looking slider out there).

ooh, nice :)

> I am seeing so far a few places where my ext-scel elisp modifications are
>  redundant to existing functions and methods, and I plan to try to
>  integrate them into the existing functionality instead of making parallel
>  code with the same intended usage.

great!
once you integrate it, please send diffs with the current svn versions, so 
that it is easy to patch, between different versions.

> Thanks in advance for any answers, feedback, or disagreement you may have
>  that would help me better understand (and eventually, hopefully, improve)
>  this code.


I hope my answers at least help a little bit,
and thanks again for taking the time to delve into this!

sincerely,
Marije

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/