December 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Repeatable VM crash

by Hilaire

I download this one http://www.mirandabanda.org/files/Cog/VM/VM.r3164/coglinux-14.48.3164.tgz and the crash is still there. Attached crash dump. Thanks Hilaire Le 06/12/2014 22:57, Eliot Miranda a Ã©crit : > Hi Esteban, > > plausibly the fix to the latest VM might fix your crash. You might > test? Fingers crossed. > > On Fri, Dec 5, 2014 at 11:26 PM, Esteban Lorenzano <estebanlm(a)gmail.com > <mailto:estebanlm@gmail.com>> wrote: > > yes, but the first step is to be sure you have the latest vm version :) > > Esteban -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Dec. 7, 2014

Re: [Pharo-dev] Duration year

by Hilaire

Hi, What is ChaltÃ©n please? Hilaire Le 02/12/2014 20:53, Maximiliano Taborda a Ã©crit : > Hi all. > > The same examples using ChaltÃ©n: > February twentyninth, 2012 next: 1 yearMeasure. "=> February > 28th, 2013" > March first, 2011 next: 1 yearMeasure. "=> March 1st, 2012" > March first, 2011 next: 12 monthsMeasure. "=> March 1st, 2012" > > Hilaire, In ChaltÃ©n a year is a year so you don't need to care about of > the number of days in it. > > Regards. > Maxi > -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Dec. 7, 2014

Re: [Pharo-dev] [Vm-dev] [ANN] ARM Stack VMs available

by Ben Coman

J. Vuletich (mail lists) wrote: > > > Quoting Chris Muller <asqueaker(a)gmail.com>: > >> On Fri, Dec 5, 2014 at 11:39 AM, Eliot Miranda >> <eliot.miranda(a)gmail.com> wrote: >>> >>> Hi Juan, >>> >>> >>> On Dec 5, 2014, at 4:56 AM, "J. Vuletich (mail lists)" >>> <juanlists(a)jvuletich.org> wrote: >>> >>>> Hi Folks, >>>> >>>> The Squeak process scheduler usually preempts a process only by >>>> another one of higher priority. And when the scheduler is ready to >>>> go back at the lower priority, it will always resume the same >>>> process that was last suspended. The only way for two or more >>>> processes of the same priority to share the processor is when the >>>> running process calls #wait or #yield. >>> >>> No. According to the blue book preempting sends the preempted process >>> to the back if its run queue so preempting forces a yield. Obviously >>> this is wrong, but that's the way it was defined. The ObjectWorks & >>> VisualWorks VMs changed this to work as you describe. >> >> Why is that wrong? By sending it to the back, one gets task-switching >> that acts like real "multitasking" as one would expect in a real >> multitasking system, without the developer having to put in explicit >> sends to #yield. Keeping it at the front "enables" multi-processing >> code to be developed incorrectly so that, one day, when it might ever >> get to a real multitasking environment, it won't work and it'll be >> harder to debug since by then its old and probably more complex. >> #yield is not a good synchronization tool.. > > Well, yes. But for that to work we'd need a highest priority process > that keeps sleeping for, lets say, 1 mSec, and does nothing. That way > all processes would be suspended and shuffled all the time. A few times I've seen the idea raised of moving process scheduling into the Image. This sounds interesting. For Pharo** I recently factored the delay scheduling event loop code out from Delay class side to its own DelayScheduler. Now actually I don't see any reason that new class needs to be tied only to Delays. It might also provide process scheduling. Where the VM currently decides which process to run, conceivably the /timingSemepahore/ could be signaled to wake up and decide which process to run next, then call back into the VM to dispatch the selected process. Having process scheduling in the VM would conceivably facilitate development of domain specific process scheduling - e.g. different for interactive UI, web servers, batch processing, robotics, control systems, real-time media. Also this would make a great environment for Computer Science courses to teach process scheduling algorithms. The following looks interesting, although I don't follow all of it... https://computeradventures.wordpress.com/tag/squeak-smalltalk-vm-scheduling/ > The way it is right now, this shuffling won't happen often, and ("bad") > code that assumes the behavior I described would work "most of the > time", breaking randomly, and more often on slower hardware (such as the > PI)... > > Is this worth doing? This "bad" code would fail all the time, and it > would be spotted and fixed. But we would break (a rather illusory) back > compatibility... Less of an issue for Pharo. Maybe this is something to consider for Pharo 5 ? cheers -ben > For instance, the code Ken is using for animating the > game cards (moving morphs around in a separate process) would break for > sure. But fixing it would also fix the issues he sees on the PI. It is > not hard to imagine that the same would happen to the sound problems Tim > found on Scratch on the PI...

Dec. 7, 2014

Re: [Pharo-dev] [Vm-dev] [ANN] ARM Stack VMs available

by J. Vuletich (mail lists)

Quoting Chris Muller <asqueaker(a)gmail.com>: > On Fri, Dec 5, 2014 at 11:39 AM, Eliot Miranda > <eliot.miranda(a)gmail.com> wrote: >> >> Hi Juan, >> >> >> On Dec 5, 2014, at 4:56 AM, "J. Vuletich (mail lists)" >> <juanlists(a)jvuletich.org> wrote: >> >>> Hi Folks, >>> >>> The Squeak process scheduler usually preempts a process only by >>> another one of higher priority. And when the scheduler is ready to >>> go back at the lower priority, it will always resume the same >>> process that was last suspended. The only way for two or more >>> processes of the same priority to share the processor is when the >>> running process calls #wait or #yield. >> >> No. According to the blue book preempting sends the preempted process >> to the back if its run queue so preempting forces a yield. Obviously >> this is wrong, but that's the way it was defined. The ObjectWorks & >> VisualWorks VMs changed this to work as you describe. > > Why is that wrong? By sending it to the back, one gets task-switching > that acts like real "multitasking" as one would expect in a real > multitasking system, without the developer having to put in explicit > sends to #yield. Keeping it at the front "enables" multi-processing > code to be developed incorrectly so that, one day, when it might ever > get to a real multitasking environment, it won't work and it'll be > harder to debug since by then its old and probably more complex. > #yield is not a good synchronization tool.. Well, yes. But for that to work we'd need a highest priority process that keeps sleeping for, lets say, 1 mSec, and does nothing. That way all processes would be suspended and shuffled all the time. The way it is right now, this shuffling won't happen often, and ("bad") code that assumes the behavior I described would work "most of the time", breaking randomly, and more often on slower hardware (such as the PI)... Is this worth doing? This "bad" code would fail all the time, and it would be spotted and fixed. But we would break (a rather illusory) back compatibility... For instance, the code Ken is using for animating the game cards (moving morphs around in a separate process) would break for sure. But fixing it would also fix the issues he sees on the PI. It is not hard to imagine that the same would happen to the sound problems Tim found on Scratch on the PI... Cheers, Juan Vuletich

Dec. 7, 2014

Re: [Pharo-dev] Monticello and Fuel

by Eliot Miranda

Hi Max, On Sat, Dec 6, 2014 at 1:43 AM, Max Leske <maxleske(a)gmail.com> wrote: > > On 06 Dec 2014, at 04:37, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Thu, Dec 4, 2014 at 11:35 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> >> > On 05 Dec 2014, at 08:02, Norbert Hartl <norbert(a)hartl.name> wrote: >> > >> > >> > >> > >> >> Am 04.12.2014 um 23:31 schrieb Thierry Goubier < >> thierry.goubier(a)gmail.com>: >> >> >> >> Hi all, >> >> >> >> I'm just wondering. >> >> >> >> Would it work to have a package format based on Fuel? >> >> >> > I doubt it would work cross platform. I don't know how fuel serializes >> WideString, LargePositiveInteger, BoxedFloat64. These differ between >> smalltalk platforms. The source as string solves that. Strings are written >> as unicode string and numbers as certain number format etc. >> >> True. Cross dialect loading isnât something we encourage to do with Fuel. >> >> @Thierry >> You said something about partial loading: that will never be possible >> with Fuel because of its pickle format. To select any partial graph you >> have to first read the entire file and rebuild the graph first (ok, you >> donât strictly have to build the graph but you still need to read the >> entire file). >> > > Hi Max, you misunderstand what partial loading means in this context. I > designed and implemented partial loading for the Parcel system in VW, and > Fuel is essentially a clean reimplementation of parcels. The idea is that > one does indeed read the entire object graph, but then only the parts of > the graph that mate with the current class hierarchy are installed, and the > bits that don't fit are stored for later. Why? So that a component can > define extensions on classes in components that may not be present. Why? > So that one can maintain a single logical component in a single package > instead of decomposing it into independently loadable fragments. > > > Makes sense. Itâs just that I often get asked if it is possible to read / > update only parts of a Fuel file, so I wanted to make it clear that that > canât work. > Right, good point. But is there a use case? For example, in effect is there a difference between being able to patch a part of a Fuel file and loading that file into an image (possibly automatically), patching the object graph and saving a new version? Lets take an example like Fuel itself. This may have specialised > marshalling and unmarshalling extensions defined on may classes, some of > which may be to do with the GUI. If we have partial loading we can load > Fuel into a headless image. The extensions on the GUI classes will simply > not be installed, *until* we load the GUI. Hence Fuel does not have to be > decomposed every time we factor the system into subcomponents. Without > partial loading Fuel must be decomposed into a series of fragments so that > it can load that part that fits into the headless base, and we have to > manage teh dependency to ensure the fragment that loads against the GUI is > loaded when the GUI is loaded. Worse still, if we cut the GUI into two > (e.g. development vs deployment tools) we have to visit the Fuel GUI > component (and potentially many other component) and decompose it into two > pieces. In practice this is extremely costly to maintain, verging on > chaos. With partial loading things are simple. > > Perhaps I should have called it partial installation, but you get the > idea. > > > Thanks for the explanation. > > > >> > >> > Norbert >> > >> >> Would that make loading faster? >> >> >> >> Does it already exist? >> >> >> >> Thanks, >> >> >> >> Thierry >> > >> >> >> > > > -- > best, > Eliot > > > -- best, Eliot

Dec. 7, 2014

Re: [Pharo-dev] New Cog VMs available

by Eliot Miranda

Oops, for http://www.mirandabanda.org/files/Cog/VM/VM.r3163/ read http://www.mirandabanda.org/files/Cog/VM/VM.r3164 On Sat, Dec 6, 2014 at 1:53 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3163/. > > CogVM binaries as per VMMaker.oscog-eem.972/r3163 > > Fix a devilishly tricky bug with 32-bit Spur and PICs in the Cogit. In > 32-bit > Spur only zero is a valid cache tag, that for Characters, due to > SmallIntegers > having both 2r11 and 2r01 as valid tags. The cache check prolog collapses > these down onto 1 by anding with 1 and hence collapses Character's 2r10 to > 0. > > The cache tag is also tested in the PIC abort routine to distinguish > between > an MNU abort and an interpret abort. A PIC MNU entry jumps to code that > first > zeros the cache tag (held in ClassReg) before calling the abort routine, > which > tests ClassReg and selects the relevant abort processing. > > Hence in 32-bit Spur if a send site is linked for Character and later > extended > to a PIC with an interpret case, that interpret case will instead invoke > MNU > processing. This is rare; first there needs to be a send to a CHaracter, > then > a send to something else which binds to something that must be interpreted. > Ouch. > > The fix is simple; if a send site that was linked with a zero cache tag > (which > can only happen in 32-bit Spur) link to an open PIC instead of to a closed > PIC, > or in the case of an MNU do not link. > > Add a debug lookup routine that only looks up (and follows forwarding > pointers). > > Add a -breakmnu vm argument that calls warning on an mnu of a specific > selector. > > Fix SmartSyntaxPlugin code generation for Spur of > > - asOop: old code assumed 4 byte oops & headers > - Unsigned old code assumed 32-bit oops > > > Affects AsyncFilePlugin, BochsIA32Plugin & FT2Plgin. > > Avoid duplication of effort in special selector send forwarding fault > handling. > > Improve stack trace printing for Newspeak and Glue by providing something > that > assumes the penultimate literal is the selector or an > AdditionalMethodState-like > thing containing it. > > Reimplement primitiveCopyObject to work for both pointer and bits objects. > This to support a good Object>>clone for Spur. > > Fix Spur's isWordsOrBytes[NonImm]:. Old code answered true for > CompiledMethods. > -- > best, > Eliot > -- best, Eliot

Dec. 7, 2014

Re: [Pharo-dev] Duration year

by stepharo

I love Chalten :) But you know it :) Stef Le 2/12/14 11:53, Maximiliano Taborda a Ã©crit : > Hi all. > > The same examples using ChaltÃ©n: > February twentyninth, 2012 next: 1 yearMeasure. "=> February > 28th, 2013" > March first, 2011 next: 1 yearMeasure. "=> March 1st, 2012" > March first, 2011 next: 12 monthsMeasure. "=> March 1st, 2012" > > Hilaire, In ChaltÃ©n a year is a year so you don't need to care about > of the number of days in it. > > Regards. > Maxi > > > 2014-12-02 16:37 GMT-03:00 Chris Cunningham <cunningham.cb(a)gmail.com > <mailto:cunningham.cb@gmail.com>>: > > GenericYear does this. The generic Year will take > '2/29/2000' asDate + 1 year "=> 28 February 2001" > In other words, we want it at the same time next year; more > importantly the same month and close to what we have now. > Also: > '3/1/2001' asDate - 1 year "=> 1 March 2000" > Still, same month - we want to be at the beginning of the month > the previous year. > > Basically, my idea (and, more importantly, what I expect - hence > my code) is that I want to pretend that we do have a field-based > representation and make it work that way. except better (since > there is no 2/29/2001). > > > Ej, which one of the followings is OK? > > '2011-03-01' asDate + 1 year "=> 2012-02-29" > > Well, I have a bug here. That needs to be fixed. > > -cbc > > > On Tue, Dec 2, 2014 at 8:34 AM, Sean P. DeNigris > <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: > > Esteban A. Maringolo wrote > > Ej, which one of the followings is OK? > > '2012-02-29' asDate + 1 year "=> 2013-02-28" > > '2011-03-01' asDate + 1 year "=> 2012-02-29" > > One solution (just ignore the source ha ha) - > http://msdn.microsoft.com/en-us/library/system.datetime.addyears%28v=vs.110… > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Duration-year-tp4791727p4793656.html > Sent from the Pharo Smalltalk Developers mailing list archive > at Nabble.com. > > >

Dec. 7, 2014

Re: [Pharo-dev] Monticello and Fuel

by stepharo

Thanks Mariano. If we could optimize common case = no change in superclass shape change and get that one fast it would be so great. Stef

Dec. 7, 2014

Re: [Pharo-dev] Monticello and Fuel

by stepharo

> What is your use case for needing it faster? > * Just every day developer use? > * CI automation? > * Something in production? Everything :) > cheers -ben > >

Dec. 7, 2014

Re: [Pharo-dev] Monticello and Fuel

by stepharo

There was a Tanker prototype. Now Levente did long time ago an analysis and he mentioned that the compilation was not that slow. Now I would love to have a binary format (fuel) as part of the mcz. because when we started Fuel it was the goal (I remember being shocked by the speed of Parcels 30 min to load RB in VW25 and 3 seconds in VW 30) Stef > Hi all, > > I'm just wondering. > > Would it work to have a package format based on Fuel? > > Would that make loading faster? > > Does it already exist? > > Thanks, > > Thierry

Dec. 7, 2014