librelist archives

« back to archive

Backend planning

Backend planning

From:
Paolo Redaelli
Date:
2012-04-03 @ 08:44
«I love it when a plan comes together..»
     Colonel John "Hannibal" Smith
How I love starting with a quote!
Quotes apart I'm really glad to see that Cyril working again on Liberty 
(see his recents commits 

<https://github.com/cadrian/Liberty/commit/9d0cf920ed0cc641333b778f5d343bb4e0cca13c>

on his new PACKRAT_PARSER)
Cyril noted that I didn't used PROCESS_POSIX and instead wrote my own, 
rought POSIX_PROCESS.
After my initial sketch about llvmec "parallelism" I would like to keep 
just one PROCESS class.

In fact I wasn't even aware that PROCESS_POSIX offered the fork-alike 
until Cyril warned me. In fact I was looking for a non-simplicistic yet 
simple design like Python's multiprocessing module; being inspired by 
Java's threading model does not change its usefulness: removing 
Pythonism from 
http://docs.python.org/library/multiprocessing.html#process-and-exceptions 
we get more or less my POSIX_PROCESS (I still haven't added join, 
terminate).

The design of PROCESS_POSIX recalled my AmigaOS heritage, making me 
wander over the ancient vfork manpage (AmigaOS didn't have memory 
protection so fork wasn't implemented but vfork was):
«.... However, in the bad  old days  a  fork(2)  would require making a 
complete copy of the caller's data space, often needlessly, *since 
usually immediately afterwards an exec(3) is done.*  Thus, for greater 
efficiency, BSD introduced the vfork() system call, ...»
PROCESS and its siblings PROCESS_[NONE|POSIX|WIN32] gave me the 
impression of having been written with vfork and exec in mind and that 
fork support was added only afterwards.
My approach to progressively parallelize the compiler starting at the 
end relies on the fact that forked processes keep the complete state of 
father at forking moment, letting me have all the informations about the 
program being compiled in the address space of the child.
At that task they are surely better, for example they have support for 
input/output redirection which are a really Unix-way to handle local 
inter-process communication: pratically they are bidirectional pipes...
I think we shall distinguish between the two main approached dealing 
with processes: forked a child to run the same code of the father and 
forking to exec some other binary. I would reverse the dependency: 
instead of PROCESS_POSIX and PROCESS_WIN32 being heirs of PROCESS I 
would make PROCESS inherit from a PLATFORM_PROCESS being in a 
platform-specific cluster, one for Win32, the other for Posix. This 
removes the need for the process factory and allow subclassing process 
without bothering about actual implementation, which - shamelessly 
enough - it's my preferred approach ;-)
As a last, naming is not literate enough... a native English would have 
named it WIN32_PROCESS and POSIX_PROCESS but former team were all French 
and being Lombard I understand that French require adjective to go after 
the name.... :-)
We could just make PROCESS deferred, providing two heirs, one to execute 
other processes, the other forking to execute the run feature of a PROCESS.

Happy hacking!
     Paolo who is always too prolix!

Re: [libertyeiffel] Backend planning

From:
Cyril Adrian
Date:
2012-04-18 @ 12:04
2012/4/3 Paolo Redaelli <paolo.redaelli@gmail.com>

> I think we shall distinguish between the two main approached dealing with
> processes: forked a child to run the same code of the father and forking to
> exec some other binary. I would reverse the dependency: instead of
> PROCESS_POSIX and PROCESS_WIN32 being heirs of PROCESS I would make PROCESS
> inherit from a PLATFORM_PROCESS being in a platform-specific cluster, one
> for Win32, the other for Posix. This removes the need for the process
> factory and allow subclassing process without bothering about actual
> implementation, which - shamelessly enough - it's my preferred approach ;-)
>
…

We could just make PROCESS deferred, providing two heirs, one to execute
> other processes, the other forking to execute the run feature of a PROCESS.


On the other hand, you can always distinguish in the factory, providing
both *fork* and *spawn* features (since it's the legacy lingo)



> As a last, naming is not literate enough... a native English would have
> named it WIN32_PROCESS and POSIX_PROCESS but former team were all French
> and being Lombard I understand that French require adjective to go after
> the name.... :-)
>

You are right; OTOH the Eiffel standard naming policy states that when you
have a common functionality then you have a common prefix; I think it's the
rule that was applied here, not an English deficiency :-)

Cheers,

*Cyril ADRIAN* *(from office)*
http://www.cadrian.net/cyril
[image: Twitter] <http://twitter.com/cadbart> [image:
LinkedIn]<http://fr.linkedin.com/in/cadrian> [image:
Google Plus] <https://plus.google.com/u/0/100388810006463519079/> [image:
Google 
Calendar]<https://www.google.com/calendar/embed?src=1t93vvvrdc26ee0f83p0cunj60%40group.calendar.google.com&ctz=Europe/Paris>
Contact me: [image: Google Talk] cyril.adrian@gmail.com
 [image: Twitter] <http://twitter.com/cadbart> Latest tweet: [Liberty]
http://t.co/uhrp9orb Cyril Adrian - cleanup
Follow @cadbart <http://twitter.com/cadbart> Reply

<http://twitter.com/?status=@cadbart%20&in_reply_to_status_id=190543992155410430&in_reply_to=cadbart>
Retweet

<http://twitter.com/?status=RT%20%40cadbart%3A%20%5BLiberty%5D%20http%3A%2F%2Ft.co%2Fuhrp9orb%20Cyril%20Adrian%20-%20cleanup>
 22:56 Apr-12<http://twitter.com/cadbart/statuses/190543992155410432>
  Get this email app!

<http://www.wisestamp.com/apps/twitter?utm_source=extension&utm_medium=email&utm_term=twitter&utm_campaign=apps>

 [image: Google Plus] <http://plus.google.com/100388810006463519079> My
latest G+: Prochains concerts de Contraste : Victor Hugo et la Musiqueen
partenariat avec l'Orchestre Besançon-Montbéliard Franche-Comté - vendredi
10/02 (Kursaal, Besançon, 20h00) - samedi 11/02 (MA scène nationale,
Montbéliard, 20h00) - dimanche 12/02
(Sa...<http://plus.google.com/100388810006463519079/posts/Nozsd4fh2M4/>
My G+ <http://plus.google.com/100388810006463519079> -
Posts<http://plus.google.com/100388810006463519079/posts/>- Add
to Circles <http://plus.google.com/100388810006463519079/about/> - 13:31
Feb-09 <http://plus.google.com/100388810006463519079>
  Get this email app!

<http://www.wisestamp.com/apps/plus?utm_source=extension&utm_medium=email&utm_term=plus&utm_campaign=apps>

  <http://www.linkedin.com/in/cyril.adrian>
  Want a signature like mine?

<http://r1.wisestamp.com/r/landing?promo=22&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_22>
Click

here.<http://r1.wisestamp.com/r/landing?promo=22&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_22>

Re: [libertyeiffel] Backend planning

From:
Paolo Redaelli
Date:
2012-04-18 @ 13:46
Il 18/04/2012 14:04, Cyril ADRIAN ha scritto:
> 2012/4/3 Paolo Redaelli <paolo.redaelli@gmail.com 
> <mailto:paolo.redaelli@gmail.com>>
>
>     I think we shall distinguish between the two main approached
>     dealing with processes: forked a child to run the same code of the
>     father and forking to exec some other binary. I would reverse the
>     dependency: instead of PROCESS_POSIX and PROCESS_WIN32 being heirs
>     of PROCESS I would make PROCESS inherit from a PLATFORM_PROCESS
>     being in a platform-specific cluster, one for Win32, the other for
>     Posix. This removes the need for the process factory and allow
>     subclassing process without bothering about actual implementation,
>     which - shamelessly enough - it's my preferred approach ;-)
>
>     … 
>
>     We could just make PROCESS deferred, providing two heirs, one to
>     execute other processes, the other forking to execute the run
>     feature of a PROCESS.
>
>
> On the other hand, you can always distinguish in the factory, 
> providing both */fork/* and */spawn/* features (since it's the legacy 
> lingo)
AFAICS you can't subclass a PROCESS implementing for example run when 
your PROCESSes objects are created by a FACTORY, except when you provide 
a specialized FACTORY. So I would rather keep both implementation, the 
one in lib (PROCESS_POSIX) and the one modelled after Python and java 
multiprocessing (POSIX_PROECSS) in wrappers/posix and let people choose. 
After all we have many other things to do and these are design issues 
that "evaporate" in actual compiled code, leaving a simple fork() call...
:-)

For example I'm quite fed of invoking short dozens of times a day. I'll 
try to resurrect eiffeldoc and add a "tree" command to discover all 
known heirs of a class, like:
heirs collection

STORABLE          -----+----COLLECTION[E]---+ LINKED_LIST[E]
TRAVERSABLE[E_]   -----|                    + ARRAY[E]
SEARCHANLE[E_]    -----+                    + .....

Or even better resurrect my gtk_eiffel_doc which is a good test bed to 
learn SE internals and to test GTK2 wrappers.....

BTW, shall I keep developing GTK2 wrappers, turn them into GTK3 or 
develop them in parallel?

Re: [libertyeiffel] Backend planning

From:
Cyril Adrian
Date:
2012-04-18 @ 14:10
2012/4/18 Paolo Redaelli <paolo.redaelli@gmail.com>

> For example I'm quite fed of invoking short dozens of times a day. I'll
> try to resurrect eiffeldoc and add a "tree" command to discover all known
> heirs of a class, like:
> heirs collection
>
> STORABLE          -----+----COLLECTION[E]---+ LINKED_LIST[E]
> TRAVERSABLE[E_]   -----|                    + ARRAY[E]
> SEARCHANLE[E_]    -----+                    + .....
>
>
I think there should not be a lot of work to revive eiffeldoc, except
compiling and running it. Am I wrong?


>  Or even better resurrect my gtk_eiffel_doc which is a good test bed to
> learn SE internals and to test GTK2 wrappers.....
>
> BTW, shall I keep developing GTK2 wrappers, turn them into GTK3 or develop
> them in parallel?
>

I don't know, it's out of my area of expertise. Naively I'd say gtk3 is the
obvious future.
I never even tried gtk3, let alone gnome3, waiting for Ubuntu LTS to have
been out for a few months :-)

Cheers

*Cyril ADRIAN* *(from office)*
http://www.cadrian.net/cyril
[image: Twitter] <http://twitter.com/cadbart> [image:
LinkedIn]<http://fr.linkedin.com/in/cadrian> [image:
Google Plus] <https://plus.google.com/u/0/100388810006463519079/> [image:
Google 
Calendar]<https://www.google.com/calendar/embed?src=1t93vvvrdc26ee0f83p0cunj60%40group.calendar.google.com&ctz=Europe/Paris>
Contact me: [image: Google Talk] cyril.adrian@gmail.com
  <http://www.linkedin.com/in/cyril.adrian>
  Want a signature like mine?

<http://r1.wisestamp.com/r/landing?promo=22&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_22>
Click

here.<http://r1.wisestamp.com/r/landing?promo=22&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_22>

Re: [libertyeiffel] Backend planning

From:
Paolo Redaelli
Date:
2012-04-18 @ 14:30
Il 18/04/2012 16:10, Cyril ADRIAN ha scritto:
> 2012/4/18 Paolo Redaelli <paolo.redaelli@gmail.com 
> <mailto:paolo.redaelli@gmail.com>>
>
>     For example I'm quite fed of invoking short dozens of times a day.
>     I'll try to resurrect eiffeldoc and add a "tree" command to
>     discover all known heirs of a class, like:
>     heirs collection
>
>     STORABLE          -----+----COLLECTION[E]---+ LINKED_LIST[E]
>     TRAVERSABLE[E_]   -----|                    + ARRAY[E]
>     SEARCHANLE[E_]    -----+                    + .....
>
>
> I think there should not be a lot of work to revive eiffeldoc, except 
> compiling and running it. Am I wrong?
Compiles and runs. And crashes. Without log because I boosted it.
I need to recompile it with a proper ACE to keep standard lib boosted 
because when all is compile in check mode is way too slow, almost 2 
orders of magnitude.
>
>     Or even better resurrect my gtk_eiffel_doc which is a good test
>     bed to learn SE internals and to test GTK2 wrappers.....
>
>     BTW, shall I keep developing GTK2 wrappers, turn them into GTK3 or
>     develop them in parallel?
>
>
> I don't know, it's out of my area of expertise. Naively I'd say gtk3 
> is the obvious future.
Ok, going 3
> I never even tried gtk3, let alone gnome3, waiting for Ubuntu LTS to 
> have been out for a few months :-)
 From the API point of view there are many changes but nothing too big, 
on runtime they rely on an external process for theming which is boring 
on low-spec machines.
I'm curious about Gnome3. Unity instead is a fat, slow cow. It's not 
snappy at all (an educated synonim of "somehow unusable") on a 3Ghz 
Pentium 4 with 1Gb ram....

Re: [libertyeiffel] Backend planning

From:
Paolo Redaelli
Date:
2012-04-03 @ 22:14
Il 03/04/2012 10:44, Paolo Redaelli ha scritto:
>      Paolo who is always too prolix!
Oh my! So prolix I forgot some issues!

   1. currently  naively changed visibility of a feature, perhaps it's
      better to make LLVM_WORKER a VISITOR of all CLASS_TEXT,
      ANONYMOUS_FEATURE than manually iterating over clusters, than
      classes than features
   2. Generic classes. I would like to avoid the current specialization
      whenever possible: code size explodes. As far as the generic is a
      reference we can avoid specialization the same way Glib implements
      containers. I shall dig old mails about it fot the details. When a
      generic class becomes a live type and the generic part is expanded
      then it's useful to maintain code specialization.
   3. Granularity of LLVM compilation unit: type, class or cluster? I
      think we shall make each cluster a separate (dynamic linked)
      library; yet llvm is more akin to a java class file or to an
      object file so it could be useful to make one unit per class (or
      live type)

Feel free to asnwer each point in a separate thread...


 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Vi aspettiamo dal 6 al 10 aprile per la Pasqua a Riccione all'hotel 
Mediterraneo: Mezza Pensione, inclusi gala' dinners, brunch pasquale, 
spettacoli, sistemazione in doppia, 3 gg Euro 353 a persona
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12259&d=4-4

Re: [libertyeiffel] Backend planning

From:
Cyril Adrian
Date:
2012-04-18 @ 11:45
Hi again,

I'm browsing through my stack of "unread" Liberty-oriented mails :-)

2012/4/4 Paolo Redaelli <paolo.redaelli@email.it>

> **
>
>    1. currently  naively changed visibility of a feature, perhaps it's
>    better to make LLVM_WORKER a VISITOR of all CLASS_TEXT, ANONYMOUS_FEATURE
>    than manually iterating over clusters, than classes than features
>
> Yes, it is, certainly. Don't export to {ANY} features that were not
designed to be.


>
>    1. Generic classes. I would like to avoid the current specialization
>    whenever possible: code size explodes. As far as the generic is a reference
>    we can avoid specialization the same way Glib implements containers. I
>    shall dig old mails about it fot the details. When a generic class becomes
>    a live type and the generic part is expanded then it's useful to maintain
>    code specialization.
>
> You can keep unspecialized a generic class for reference types. On the
other hand, expanded types *need* specialization, because there is no
conformance and because of their very nature (the "container" must be aware
of the contained object layout).

To make it a simple rule, I'd break unspecialization (i.e. do specialize)
each time there is non-conformance.

The problem is, the LLVM bytecode producer is already too far in the
compilation chain: specialization is already done. It's part of
SmartEiffel's core engine. And changing that will also mean changing the C
code compiler (not mentioning the brain power to change such a core
feature).

mmm… quite an idea now :-) Let me finish the packrat parser (I'm writing
the equivalent of old
yepp<http://ese.svn.sourceforge.net/viewvc/ese/trunk/src/eiffel/tools/yepp/>
but
using packrat 
technology<http://en.wikipedia.org/wiki/Parsing_expression_grammar>),
and I'll try to give it some thought.


>    1. Granularity of LLVM compilation unit: type, class or cluster? I
>    think we shall make each cluster a separate (dynamic linked) library; yet
>    llvm is more akin to a java class file or to an object file so it could be
>    useful to make one unit per class (or live type)
>
> I'd say type, because of the expanded specialization. Why embed unneeded
specializations?… It also depends on LLVM's capacity to remove dead code.

Cheers,

*Cyril ADRIAN* *(from office)*
http://www.cadrian.net/cyril
[image: Twitter] <http://twitter.com/cadbart> [image:
LinkedIn]<http://fr.linkedin.com/in/cadrian> [image:
Google Plus] <https://plus.google.com/u/0/100388810006463519079/> [image:
Google 
Calendar]<https://www.google.com/calendar/embed?src=1t93vvvrdc26ee0f83p0cunj60%40group.calendar.google.com&ctz=Europe/Paris>
Contact me: [image: Google Talk] cyril.adrian@gmail.com
 [image: Twitter] <http://twitter.com/cadbart> Latest tweet: [Liberty]
http://t.co/uhrp9orb Cyril Adrian - cleanup
Follow @cadbart <http://twitter.com/cadbart> Reply

<http://twitter.com/?status=@cadbart%20&in_reply_to_status_id=190543992155410430&in_reply_to=cadbart>
Retweet

<http://twitter.com/?status=RT%20%40cadbart%3A%20%5BLiberty%5D%20http%3A%2F%2Ft.co%2Fuhrp9orb%20Cyril%20Adrian%20-%20cleanup>
 22:56 Apr-12<http://twitter.com/cadbart/statuses/190543992155410432>
  Get this email app!

<http://www.wisestamp.com/apps/twitter?utm_source=extension&utm_medium=email&utm_term=twitter&utm_campaign=apps>

 [image: Google Plus] <http://plus.google.com/100388810006463519079> My
latest G+: Prochains concerts de Contraste : Victor Hugo et la Musiqueen
partenariat avec l'Orchestre Besançon-Montbéliard Franche-Comté - vendredi
10/02 (Kursaal, Besançon, 20h00) - samedi 11/02 (MA scène nationale,
Montbéliard, 20h00) - dimanche 12/02
(Sa...<http://plus.google.com/100388810006463519079/posts/Nozsd4fh2M4/>
My G+ <http://plus.google.com/100388810006463519079> -
Posts<http://plus.google.com/100388810006463519079/posts/>- Add
to Circles <http://plus.google.com/100388810006463519079/about/> - 13:31
Feb-09 <http://plus.google.com/100388810006463519079>
  Get this email app!

<http://www.wisestamp.com/apps/plus?utm_source=extension&utm_medium=email&utm_term=plus&utm_campaign=apps>

  <http://www.linkedin.com/in/cyril.adrian>
  Want a signature like mine?

<http://r1.wisestamp.com/r/landing?promo=22&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_22>
Click

here.<http://r1.wisestamp.com/r/landing?promo=22&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_22>