March 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by Stefan Marr

Hi: On 12 Mar 2013, at 11:43, phil(a)highoctane.be wrote: > The Utilities thing is just used to display a progress dialog > inform:during:, so that's easy. Also String asText form for Display > can be solved with a blank form. Some of that has been reported last year, including patches: https://code.google.com/p/cog/issues/detail?id=106 https://code.google.com/p/cog/issues/detail?id=107 https://code.google.com/p/cog/issues/detail?id=108 It got never integrated... Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

March 12, 2013

Re: [Pharo-project] GSoC13: Distributed Issue Tracker

by Stephan Eggermont

GÃ¶ran wrote: >Would you like me to dig out the Gjallar codebase and share it with you? >With some annotations? There should be lots to pick/learn from it. I have a Gjallar0.4 image here. Any changes since then? Stephan

March 12, 2013

Re: [Pharo-project] [Moose-dev] Re: where to report vm crashes? (while running Moose tests)

by Camillo Bruni

On 2013-03-12, at 10:17, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Camillo, > > On 12 Mar 2013, at 09:39, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> from that point of view, it is just a warning. Unless you do some fancy >> new FileSystem stuff it will continue to work with 2.0 and for a while with >> 3.0. > > Is it not possible to clarify *exactly* what is missing and will not work well. > > Right now this is like a mystery. > > We are all developers and capable of understanding a technical explanation ;-) > > Which primitives are we talking about, how are they used and what end user effect do they have ? > > I know that NativeBoost is an important difference. The question is, will the image start without proper NB support and will something be broken if NB is non-functional (apart from NB code itself, I mean high level normal stuff) ? Well so far there is only some FileSystem primitives, and besides the tests nobody ever relied on getting the permissions or checks if a file is an symlink. But we can do that now. NativeBoost is shipped with 2.0 but not yet used in the Kernel, but this is going to change in 3.0 where we hope to rewrite the UI driver talking to Cairo using an NativeBoost-FFI binding. The thing is, I don't want to care and define which external VMs work with which Pharo version. (Still, yes you can run Pharo 20 on CogVM, we just don't like it :P ) Pharo ships and runs only with the Pharo and the PharoS VM. Currently the situation is not perfect with our VMs being unstable

March 12, 2013

[Pharo-project] the PharoTeam right now

by StÃ©phane Ducasse

http://www.pbase.com/giancarlob/image/91276919 or kind of :) Meteo France called the 25 cm of snow falling on us a "remarkable" event. the last bite of winter is bitting us hard :) Stef

March 12, 2013

[Pharo-project] Zeroconf: config command issue - oops

by phil＠highoctane.be

In the book, we have that config should show the help. As in: Examples: # display this help message $PharoVM My.image config but... PhilMac:~/Documents/Smalltalk/2-MyWorkspaces/workspaceZeroConf20130312 philippeback$] ./vm.sh Pharo.image config ==== Startup Error: SubscriptOutOfBounds: 1 OrderedCollection(Object)>>errorSubscriptBounds: OrderedCollection>>ensureBoundsFrom:to: OrderedCollection>>at: CommandLineArguments>>argumentAt: ConfigurationCommandLineHandler(CommandLineHandler)>>argumentAt: ConfigurationCommandLineHandler>>loadRepositoryURL ConfigurationCommandLineHandler>>repositoryURL ConfigurationCommandLineHandler>>gofer ConfigurationCommandLineHandler>>loadConfigurationNames ConfigurationCommandLineHandler>>listConfigurations ConfigurationCommandLineHandler>>list ConfigurationCommandLineHandler>>activate ConfigurationCommandLineHandler class(CommandLineHandler class)>>activateWith: DefaultCommandLineHandler>>handleSubcommand DefaultCommandLineHandler>>handleArgument: DefaultCommandLineHandler>>activate DefaultCommandLineHandler class>>startUp: in Block: [self new activate] BlockClosure>>cull: SmalltalkImage>>executeDeferredStartupActions: in Block: [each cull: resuming] BlockClosure>>on:do: SmalltalkImage>>logStartUpErrorDuring:into:tryDebugger: SmalltalkImage>>executeDeferredStartupActions: in Block: [:each | self... OrderedCollection>>do: SmalltalkImage>>executeDeferredStartupActions: SmalltalkImage>>startupImage:snapshotWorked: SmalltalkImage>>snapshot:andQuit: SmalltalkImage>>saveImageInFileNamed: SmalltalkImage>>saveAs: SaveCommandLineHandler>>saveImage SaveCommandLineHandler>>activate Got startup errors: SubscriptOutOfBounds: 1 Is this the behavior we want? It is kind of scary actually. Phil

March 12, 2013

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by Frank Shearar

On 12 March 2013 10:43, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > The Utilities thing is just used to display a progress dialog > inform:during:, so that's easy. Also String asText form for Display > can be solved with a blank form. > > I am now stuck on getting a 6504 image format. What are you getting stuck on? You should just need to run the image with an Interpreter VM (grab an Interpreter VM off http://www.squeakvm.org/unix/ (stable releases) or http://build.squeak.org/job/InterpreterVM/lastSuccessfulBuild/artifact/ (bleeding edge)) and save the image. frank > Phil > > 2013/3/12 stephane ducasse <stephane.ducasse(a)free.fr>: >> >> On Mar 12, 2013, at 11:02 AM, phil(a)highoctane.be wrote: >> >>> Thank you very much. It makes a lot of sense doing things the Pharo way. >>> >>> Now, I have been trying to get the InterpreterSimulator to work in >>> Pharo but there are some things to fix before being able to do so (one >>> is to have an image in 6504 format but hey, this is for me learning) >>> Classes like Utility etc that aren't in the image anymore. >>> >>> I had a chat with Bert yesterday and he actually helped me get the >>> Interpreter starting. >>> >>> t would be nice to have Pharo VMMaker have a working base interpreter >>> (in Smalltalk, running inside the image I mean). >> >> yes it would be nice. Now have Utilities monster kind of class in our system is not something we like. :) >> >> >>> Maybe should I look at another class, like CogInterpreter? >>> >>> Phil >>> >>> 2013/3/12 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>> We use an automated building method that tries to be exactly the same in each platform. We decided not to create bundles but dylibs because bundles are mac-specific stuff and .dylibs same (but for mac) as .so and .dll. >>>> Our process builds the vm, the plugins and the third party libraries as an all-in-one. Eliot builds are hand made, and when there is a process (like the autotool for unix builds), they are platform-specific. >>>> >>>> TL;DR: Is easier for us to build all the vm stuff in an unified way :) >>>> >>>> Esteban >>>> >>>> On Mar 12, 2013, at 10:49 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>> >>>>> Eliot's CogVM vs PharoVM on Mac application contents. Quite different. >>>>> >>>>> And worth some explanations :-) Why is it that way? >>>>> >>>>> Phil >>>>> >>>>> 2013/3/12 Stephan Eggermont <stephan(a)stack.nl>: >>>>>>> It would be good to have a parallel job, but the problem is that you will >>>>>>> get a message saying that the VM is too old for the Pharo 2.0 image. >>>>>> >>>>>> I started the latest MOOSE image on Eliots latest VM on mac. >>>>>> It still has the 'old vm' warning. >>>>>> Adding a monticello repository (directory) doesn't work. >>>>>> Tests are still running >>>>>> >>>>>> Stephan >>>>>> >>>>>> >>>>> <2013-03-12_10-43-37.png> >>>> >>>> >>> >> >> >

March 12, 2013

Re: [Pharo-project] [Seaside] GSoC13: Distributed Issue Tracker

by GÃ¶ran Krampe

Hey folks! Would you like me to dig out the Gjallar codebase and share it with you? With some annotations? There should be lots to pick/learn from it. regards, GÃ¶ran

March 12, 2013

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by Esteban Lorenzano

the layout for iOS apps is very different than for OSX apps... that's why iOS has a different arrangement. - also, apple does not allows dynamic links for iOS, so every included plugin has to be internal. - also, we are not including many of the plugins (those who does not has sense in iOS, or has not been ported yet), that's why it is so small. Esteban On Mar 12, 2013, at 11:27 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > The iOS VM has another layout even. And the exe is smaller than 600KB. > > Phil > > > 2013/3/12 Esteban Lorenzano <estebanlm(a)gmail.com>: >> not exactly, but yes, some of the plugins that are internal in Eliot's are external for pharo (no real important reason: we decided to put as external as many as possible :) >> >> Esteban >> >> On Mar 12, 2013, at 11:15 AM, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> >>> Also, it looks like the Pharo VM uses only external plugins? The >>> Squeak VM has a bunch of those plugins, but as internal ones. That's >>> probably most of the difference Phil's asking about. >>> >>> frank >>> >>> On 12 March 2013 09:57, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> We use an automated building method that tries to be exactly the same in each platform. We decided not to create bundles but dylibs because bundles are mac-specific stuff and .dylibs same (but for mac) as .so and .dll. >>>> Our process builds the vm, the plugins and the third party libraries as an all-in-one. Eliot builds are hand made, and when there is a process (like the autotool for unix builds), they are platform-specific. >>>> >>>> TL;DR: Is easier for us to build all the vm stuff in an unified way :) >>>> >>>> Esteban >>>> >>>> On Mar 12, 2013, at 10:49 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>> >>>>> Eliot's CogVM vs PharoVM on Mac application contents. Quite different. >>>>> >>>>> And worth some explanations :-) Why is it that way? >>>>> >>>>> Phil >>>>> >>>>> 2013/3/12 Stephan Eggermont <stephan(a)stack.nl>: >>>>>>> It would be good to have a parallel job, but the problem is that you will >>>>>>> get a message saying that the VM is too old for the Pharo 2.0 image. >>>>>> >>>>>> I started the latest MOOSE image on Eliots latest VM on mac. >>>>>> It still has the 'old vm' warning. >>>>>> Adding a monticello repository (directory) doesn't work. >>>>>> Tests are still running >>>>>> >>>>>> Stephan >>>>>> >>>>>> >>>>> <2013-03-12_10-43-37.png> >>>> >>>> >>> >> >> > <2013-03-12_11-24-37.png>

March 12, 2013

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by phil＠highoctane.be

No, I mean: (InterpreterSimulator initializeWithOptions: Dictionary new). (InterpreterSimulator new openOn: Smalltalk imageName) test. working. Of course, this does the trick on its own image, so, I could be happy enough with whichever image can be used there. That's in an image with VMMaker of course. VMMaker-Interpreter and VMMaker-InterpreterSimulation I'd like to dig inside the image format and how all of that works. As I am doing some experiments with Spoon and minimal object memories, this could come handy to improve my understanding (which is currently abysmally low). Phil 2013/3/12 Esteban Lorenzano <estebanlm(a)gmail.com>: > by base Interpreter you mean an InterpreterVM? > > On Mar 12, 2013, at 11:02 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> Thank you very much. It makes a lot of sense doing things the Pharo way. >> >> Now, I have been trying to get the InterpreterSimulator to work in >> Pharo but there are some things to fix before being able to do so (one >> is to have an image in 6504 format but hey, this is for me learning) >> Classes like Utility etc that aren't in the image anymore. >> >> I had a chat with Bert yesterday and he actually helped me get the >> Interpreter starting. >> >> t would be nice to have Pharo VMMaker have a working base interpreter >> (in Smalltalk, running inside the image I mean). >> >> Maybe should I look at another class, like CogInterpreter? >> >> Phil >> >> 2013/3/12 Esteban Lorenzano <estebanlm(a)gmail.com>: >>> We use an automated building method that tries to be exactly the same in each platform. We decided not to create bundles but dylibs because bundles are mac-specific stuff and .dylibs same (but for mac) as .so and .dll. >>> Our process builds the vm, the plugins and the third party libraries as an all-in-one. Eliot builds are hand made, and when there is a process (like the autotool for unix builds), they are platform-specific. >>> >>> TL;DR: Is easier for us to build all the vm stuff in an unified way :) >>> >>> Esteban >>> >>> On Mar 12, 2013, at 10:49 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>> >>>> Eliot's CogVM vs PharoVM on Mac application contents. Quite different. >>>> >>>> And worth some explanations :-) Why is it that way? >>>> >>>> Phil >>>> >>>> 2013/3/12 Stephan Eggermont <stephan(a)stack.nl>: >>>>>> It would be good to have a parallel job, but the problem is that you will >>>>>> get a message saying that the VM is too old for the Pharo 2.0 image. >>>>> >>>>> I started the latest MOOSE image on Eliots latest VM on mac. >>>>> It still has the 'old vm' warning. >>>>> Adding a monticello repository (directory) doesn't work. >>>>> Tests are still running >>>>> >>>>> Stephan >>>>> >>>>> >>>> <2013-03-12_10-43-37.png> >>> >>> >> > >

March 12, 2013

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by phil＠highoctane.be

The Utilities thing is just used to display a progress dialog inform:during:, so that's easy. Also String asText form for Display can be solved with a blank form. I am now stuck on getting a 6504 image format. Phil 2013/3/12 stephane ducasse <stephane.ducasse(a)free.fr>: > > On Mar 12, 2013, at 11:02 AM, phil(a)highoctane.be wrote: > >> Thank you very much. It makes a lot of sense doing things the Pharo way. >> >> Now, I have been trying to get the InterpreterSimulator to work in >> Pharo but there are some things to fix before being able to do so (one >> is to have an image in 6504 format but hey, this is for me learning) >> Classes like Utility etc that aren't in the image anymore. >> >> I had a chat with Bert yesterday and he actually helped me get the >> Interpreter starting. >> >> t would be nice to have Pharo VMMaker have a working base interpreter >> (in Smalltalk, running inside the image I mean). > > yes it would be nice. Now have Utilities monster kind of class in our system is not something we like. :) > > >> Maybe should I look at another class, like CogInterpreter? >> >> Phil >> >> 2013/3/12 Esteban Lorenzano <estebanlm(a)gmail.com>: >>> We use an automated building method that tries to be exactly the same in each platform. We decided not to create bundles but dylibs because bundles are mac-specific stuff and .dylibs same (but for mac) as .so and .dll. >>> Our process builds the vm, the plugins and the third party libraries as an all-in-one. Eliot builds are hand made, and when there is a process (like the autotool for unix builds), they are platform-specific. >>> >>> TL;DR: Is easier for us to build all the vm stuff in an unified way :) >>> >>> Esteban >>> >>> On Mar 12, 2013, at 10:49 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>> >>>> Eliot's CogVM vs PharoVM on Mac application contents. Quite different. >>>> >>>> And worth some explanations :-) Why is it that way? >>>> >>>> Phil >>>> >>>> 2013/3/12 Stephan Eggermont <stephan(a)stack.nl>: >>>>>> It would be good to have a parallel job, but the problem is that you will >>>>>> get a message saying that the VM is too old for the Pharo 2.0 image. >>>>> >>>>> I started the latest MOOSE image on Eliots latest VM on mac. >>>>> It still has the 'old vm' warning. >>>>> Adding a monticello repository (directory) doesn't work. >>>>> Tests are still running >>>>> >>>>> Stephan >>>>> >>>>> >>>> <2013-03-12_10-43-37.png> >>> >>> >> > >

March 12, 2013