<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 3, 2017 at 5:57 AM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 2, 2017 at 9:54 AM, K K Subbu <span dir="ltr"><<a href="mailto:kksubbu.ml@gmail.com" target="_blank">kksubbu.ml@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-m_431882177324794512gmail-"><br>
On Friday 02 June 2017 04:50 PM, Holger Freyther wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
+1. I would go further and propose that plugins, other than those<br>
which are integral to VM[1], be moved into separate projects and<br>
built in their own tree with no references to vm source paths. They<br>
should be free to organize their platform-specific and<br>
platform-independent code and makefiles.<br>
</blockquote>
<br>
why? How many plugins are used that don't ship with the pharo-vm (or<br>
squeakvm)? I have to say I like the pharo-vm approach a lot where the<br>
VMMaker* packages and generated sources sit next to each other.<br>
</blockquote>
<br></span>
My proposal is to loosen build time coupling, not packaging. Nothing prevents plugins built out of tree from being built, installed and shipped together. Supporting out of tree plugins allows others to extend a VM even long after its release.<br>
<br>
Eliot has already responded to your example in detail, so I will not dwell upon it further, except to point out that we need a command line tool to generate a .c file directly from the plugin's mcz file. Then we can create a Make rule to compile a .o and get rid of .c file. e.g.<br>
<br>
 FooPlugin.o : FooPlugin.mcz<br>
        squeak -headless vmmaker.image <a href="http://gencc.st" rel="noreferrer" target="_blank">gencc.st</a> FooPlugin.mcz<br>
        cc -c ... FooPlugin.c<br>
        rm -f FooPlugin.c<br></blockquote><div><br></div><div>Over my dead body.  The make must *NEVER* be done like this.  The problems are many:</div><div>- the VM so produced is undebuggable.  There is no source for FooPlugin.c; it has been deleted</div><div>- the build is slow; building a VMMaker image (the necessary prerequisite for st2c) takes a long time, mush longer than the st2c step</div><div>- unless FooPlugin.mcz is versioned then the VM so produced is unversioned and if  FooPlugin.mcz /is/ versioned then there's no reason why the plugin can't be produced using the normal workflow, generate C source, check it in to opensmalltalk/vm, build, and that way we have a versioned entity and break the dependency of builds requiring VMMaker</div><div><br></div></div></div></div></blockquote><div><br></div><div>And I remember it mentioned a while ago, the bug is sometimes in the generation-code, so you want historical access to both mcz and generated-C to help debug that. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>Look, I just spent several years persuading the Paro community that generating source and then building was a really bad idea and they should shelve it and now someone is trying to bring it back.  No, no, and thrice times, no.</div><div><br></div></div></div></div></blockquote><div><br></div><div><br></div><div>I think Pharo has not completely abandoned generating C-sources, although its now a sideline activity...</div><div>On Wed, May 31, 2017 at 2:48 PM, Esteban Lorenzano <span dir="ltr"><<a href="mailto:estebanlm@gmail.com" target="_blank">estebanlm@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>In any case, in the “pharo side” of things, we keep a parallel CI process who does this: </div><div><br></div><div>1) there is a development branch that keep all sources we need: the osvm *and* all monticello packages (filetree format) acting as a mirror that merges changes and executes all building process (including generating sources) and testing (we run all pharo tests as a way to test the VM). This is done just for being sure the CI is green and no artifact is created. This is how I have early reported problem in VM generation before.</div><div>2) in parallel the build follows the “normal” process on opensmalltalk-vm and everything is build there. This generates a “latest” build which is published in pharo servers so people can test (but this binary could be wrong as is not something declared as “stable”</div></div></blockquote></div><div><br></div><div><br></div><div>I do wonder from time to time is why the C-generation can't be done as part of an opensmalltalk-vm CI process?  The manual process is a bit opaque, and a CI process would be better than documentation.  One possibility of doing it via CI could be generating from both Squeak and Pharo and checking the output is identical (assuming that might be useful).</div><div><br></div><div>IIRC Eliot didn't want the generated-C updated in the Cog branch for every VMMaker commit.  A way to conform to this would be the CI updating the generated C in a side branch, and only when deemed worthy it could be integrated into the Cog branch via a simple merge rather than a one-time manual generation run.  </div><div><br></div><div>Eliot,  If you're receptive to this idea, I'd be interested in working on this.  What concerns would you have with it?</div><div><br></div><div>cheers -ben</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
where st2c should generate the .c file for FooPlugin from its Slang code in its package or from a .st file. There is no need for .c file to be human readable or be subject to version control. That will be very messy.<br></blockquote><div><br></div><div>_yes_.  _there_. _is_.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Regards .. Subbu</blockquote></div><div><br></div>-- <br><div class="gmail-m_431882177324794512gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>
<br></blockquote></div><br></div></div>