[Vm-dev] script to add internal plugins ?

[Sophie Kaleba]

Update :

I did add the plugins to the file. That was the easy part, it went well.

Then it got trickier when I tried to actually build the (Pharo) VM
(build.linux32x86/pharo.cog.spur/build.itimerheatbeat) with my brand new
plugins :

- at first, I had an error : "can't find PharoV50.sources".

(I cloned the opensmalltalk-vm directory,
 ran updateSCCSVersions
and then went in the "build.linux32x86/pharo.cog.spur/build.itimerheatbeat"
and ran ./mvm -f )

Manually adding a "sources" directory containing the missing file solved
the problem
Did I miss something on that part?


-OK, now, the VM is built with this small hack.

When I try to use the VMProfiler (which works fine using the latest squeak
VM from bintray), I get a segmentation fault, with this message :

*** stack smashing detected ***: ./squeak terminated
output file stack is full.

I already ran into this error when I first tried to run the VMProfiler a
few weeks ago. At that time, I was using a built Squeak VM (still
linux32x86 , cog.spur, itimer).
Seeing that I got the same problem building both pharo and squeak vm (and
not having it with vm I haven't actually built), I guess it has something
to do with my environment.
I was told it could be caused by a near-full disk, but I still have 8Gb+ of
free space so, well.

Does somebody have any idea about what could cause this error ? It would
actually help me narrowing down the possibilities...
I am using ubuntu 15.10 (old) so I will update it later today and check if
it solves the problem.
I will also try to update some libs, just in case.

In the meantime, i will make a PR with the modified plugins files anyway,
and see if it gets rejected or not.

Sophie



2017-05-11 3:18 GMT+02:00 Ben Coman <btc at openinworld.com>:

>
> On Thu, May 11, 2017 at 8:08 AM, tim Rowledge <tim at rowledge.org> wrote:
> >
> >
> >> On 10-05-2017, at 4:57 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> >>
> >>
> >> On Wed, May 10, 2017 at 02:36:20PM -0700, tim Rowledge wrote:
> >>>
> >>>
> >>>> On 10-05-2017, at 1:47 PM, Sophie Kaleba <sophie.kaleba at gmail.com>
> wrote:
> >>>>
> >>>> Hi Tim,
> >>>>
> >>>> I hadn't thought about that, thanks ! I will make sure not to create
> any duplicate of these plugins
> >>>
> >>> I???ve never thought to experiment and see what happens if one tried
> to make both internal and external versions of the same plugin. I???d guess
> that it might not cause any problems in most cases.. hmm, unless on some
> platform you actually have to compile with different flags, and then maybe
> there???d be problems if the internal version were compiled with flag A,
> the ???.o??? file were left around, the external version compile process
> found it, therefore didn???t compile with flag B, thus making something
> fail?
> >>>
> >>
> >> I have not checked in a while, but I am pretty sure that it is perfectly
> >> ok to have both an internally compiled plugin as part of the main VM
> >> executable, and also an externally compiled version of the same plugin
> >> (a loadable module in a file separate from the main VM executable). In
> >> that case, the external plugin should override the internal one.
> >>
> >> The idea is that it should be easy to make an external plugin that might
> >> add some new behaviour, and the plugin developer should be able to do
> >> this without waiting for somebody else to distribute a new VM.
> >>
> >> If this is not the case, then it certainly /should/ be. Tim, weren't
> >> you one of the people who invented this loadable module stuff in the
> >> first place?
> >
> > D’oh, of course you’re right. Oh the joys of aging…
> >
> > And what I *should* have said was that I haven’t experimented with
> making internal and external versions within the same build process, given
> faint concerns about the object files maybe confusing the matter if one
> version is built and (incorrect) object files are left for the next version
> make-rule to find.
> > So er, something like build BlobbyPlugin.c -> BlobbyPlugin.o -> link to
> make vm with internal BlobbyPlugin followed almost immediately by build
> BlobbyPlugin.c -> ooh, already got BlobbyPlugin.o -> make library
> BlobbyPlugin.la
> > I’m imagining a situation where BlobbyPlugin.o actually ought to have
> been (re)compiled with subtly different flags in order to make a correct
> library. I may be being paranoid. Or maybe the OS is actually out to get
> me...
>
> Remember, just because you think you're paranoid doesn't mean they're
> not watching you.
>
> HTH  ;)
> cheers -ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170511/44d6cc3f/attachment.html>