Re: [sc-dev] questions about scel

[Dan Stowell <danstowell+sc3@xxxxxxxxx>]

2009/12/29 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?

Without having looked, IIRC sclang's Pipe class can only handle read
*or* write pipes and not two-way, meaning that you need to establish a
fifo as a kind of intermediary which allows you to get both input and
output. This is how it has been for things like the OctaveSC class at
least.

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

Not "primitive" but "private". Since sc lang doesn't have private
methods this is a convention for marking methods that users shouldn't
really invoke from outside, although there's nothing that'll stop them
doing so.

Dan

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



-- 
http://www.mcld.co.uk

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