Re: [sc-dev] questions about scel

[stefan kersten <sk@xxxxxxxxxx>]

On 29.12.09 22:35, nescivi wrote:
> I hope Stefan Kersten, who wrote scel, is also reading this thread, so he can 
> shed some light on stuff too.

sure, i'm happy this code sees some attention and usage ;)

>> 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.

basically stdin is for executing SC code, stdout is for displaying evaluation
output and the fifo is for sending lisp code to emacs for evaluation.

>> 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. :)

there's no real solution to the (a)synchronicity problem, unless SC adopts a way
of blocking the main interpreter thread. i admit this continuation passing style
is a bit cumbersome, it could be worthwhile to write a primitive for fifo
communcation with emacs -- the primitive could block while waiting for a
response and thus RPC would be synchronous.

>> 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.

as marije said, classInitTree is just a request to initialize something the
current class depends on. imo, omiting the initialization of EmacsInterface in
Emacs would be bad style, because it assumes we know EmacsInterface is being
initialized in EmacsDocument.

>> 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.

sclang-get-post-buffer just returns the post buffer and creates it if it doesn't
exist yet. with-sclang-post-buffer also sets current-buffer, which might not be
desirable in some situations ...

>>  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.

line 113 in sclang-interp.el indeed seems to be redundant:

111 (defun sclang-init-post-buffer ()
112   "Initialize post buffer."
113   (get-buffer-create sclang-post-buffer)
114   (with-sclang-post-buffer
115     ...

>> 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 :)

yes, maybe this diagram could find a place on the wiki or in the scel source
directory?

<sk>

_______________________________________________
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/