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

Re: [Pharo-dev] ARM, Raspbian: Good new everyone, Raspbian display is now fixed

by Serge Stinckwich

Thank you for this really nice work ! Don't forget at the end to produce a Raspbian deb package so everyone could easily install a Pharo VM and image on a RPi. Regards On Thu, Feb 13, 2014 at 5:38 PM, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: > Hello > I finally successfully fixed the PharoS bug on Raspbian. > So now the UI is not completely block it is just slow. > > As it is not yet merge with the common Pharo repository (the pull request is > send), but you can test it here: > https://ci.inria.fr/pharo-contribution/view/RaspberryPi-Experimentation/job… > > > Best Regards > Jean Baptiste Arnaud > jbaptiste.arnaud(a)gmail.com > > > > > > > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Feb. 19, 2014

Re: [Pharo-dev] [Vm-dev] Re: On things we do when our stack overflows

by Sven Van Caekenberghe

On 19 Feb 2014, at 02:53, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Tue, Feb 18, 2014 at 7:30 AM, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: > > Hi: > > On 18 Feb 2014, at 15:58, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > The VM could sure use stack overflow protection, it would/could help catch numerous 'hangs' due to infinite loops. > > But Smalltalk, having a spaghetti stack composed of contexts needs a different approach. The stack guard page won't work. The original approach of waiting for space to run out and signalling the low space semaphore doesn't scale, and hasn't been well-maintained, often resulting in systems that lock-up before they open a debugger on an offending process when space is low (it can be difficult to pick the right process also). Counting the stack depth periodically is sloooow, but something the VM can optimize unsafely (e.g. imagine an inst var in Process that records a per-process stack depth, and imagine that is updated by the VM on process switch and that the VM can efficiently compute the stack depth of the part of the process's context chain that is mapped to stack pages in the stack zone; this is fine provided nothing edits the process's stack chain explicitly, as does e.g. Seaside). So this is not a trivial problem to solve satisfactorily. > > To understand how we should implement this one really should understand the architecture of context-to-stack mapping in the Cog and Stack VMs. You can read my blog for that. > > Here's a hack off the top of my head: Process contains an inst var which records the number of contexts it creates. This count is not accurate. In Cog and the Stack VM it records only contexts created when the VM evacuates a page of contexts. In the classic Interpreter VM we count context allocations). Whenever a process's context count exceeds a given threshold, its actual depth is counted (accurately) and if this exceeds a second threshold, the process is interrupted. These thresholds need to be known to the VM and hence be vm parameters. > > > Thoughts? Other ideas? Sounds right (not knowing the details underneath): the performance hit of the protection should indeed be as low as possible. It does not have to be super accurate. The UX should be something like this (www.lispworks.com) CL-USER 1 > (defun deep-recursion (n) (if (< n 1000) (deep-recursion (1+ n)) 'done)) DEEP-RECURSION CL-USER 2 > (deep-recursion 1) Stack overflow (stack size 31744). 1 (continue) Extend stack by 50%. 2 (abort) Return to level 0. 3 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. CL-USER 3 : 1 > :c Stack overflow (stack size 48128). 1 (continue) Extend stack by 50%. 2 (abort) Return to level 0. 3 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. CL-USER 4 : 1 > :c Stack overflow (stack size 80896). 1 (continue) Extend stack by 50%. 2 (abort) Return to level 0. 3 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. CL-USER 5 : 1 > :c DONE > > > > On 18 Feb 2014, at 13:08, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > > > >> Hi there, > >> > >> Toyota shoot its foot and learnt how not to anymore. > >> > >> This is a nice read on the things our software do when the stack overflows. > >> Are We Shooting Ourselves in the Foot with Stack Overflow? > >> http://embeddedgurus.com/state-space/2014/02/are-we-shooting-ourselves-in-t… > >> > >> The question on the table is > >> > >> are we following time proven safety rules when the same thing happen to our VM? > > From the top of my head, I would expect operating systems for non-embedded devises to allocate a protected page at the end of the stack to detect stack overflows. > And, most of the standard OSes should use Address Space Layout Randomization, which you need to turn off explicitly if you actually want to make sure that your stack is at a predefined position. > > I think, this article is really targeted towards embedded systems, where you might not even got a MMU. > > And, if you are interested in those things, it might be best to follow Eliotâs suggestion and discuss it on the VM list. > > Best regards > Stefan > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > > > > > -- > best, > Eliot

Feb. 19, 2014

Re: [Pharo-dev] Versionner in pharo 3.0

by Christophe Demarey

Hi Norbert, Le 19 fÃ©vr. 2014 Ã 13:32, Norbert Hartl a Ã©crit : > Is anybody using Versionner in 3.0? I would be really interested in some success reports. In my case I cannot achieve much with it. People just start to use Versionner since it was integrated lately (vm problem). > I really donât get when it is creating a baseline version and when a static version. Releasing a valid baseline produces a static version that looks good but also it creates a new baseline. Why? baseline = dev version numbered version = release A project evolves or is ... dead (kind of). That's why a new development version is always generated after a release. I had a discussion with Damien this morning. He argued that Versionner should be able to able to reuse baselines until there is a change to this baseline ... and is right (need to work on that). To avoid problems, Versionner now always create a new baseline for the next development version. > Because creating a baseline in any of my projects lead to a bogus configuration. Versionner rewrites project dependency wrongly (projects are named after configurations and not after names I give them. loads: directives are stripped off but references in the rest of the configuration are not changed accordingly). Yes, you reported this bug: https://pharo.fogbugz.com/f/cases/12903. I will work on this one tomorrow. > In my current project it creates a baseline with the same version as a static version that already exists. static version => release baseline => new dev version > It is a shame because it looks so good but all the funtionalities do not work in my projects except âcommit the projectâ. I hope Iâm doing something wrong but then I downloaded a fresh pharo 3.0 this morning and loaded my config and went from there. Are there some other bugs not reported? > How to proceed? What kind of test case should I deliver. I think Versionner is pretty important and I should be usable in 3.0. Reporting bugs and provide a way to reproduce is a good start point. Thank you for taking time to test and to report problems, Christophe.

Feb. 19, 2014

Re: [Pharo-dev] Test for the string class available on SmalltalkHub

by btc＠openinworld.com

Feb. 19, 2014

Re: [Pharo-dev] Bug in DateAndTime class

by Diego Lont

I think a zero time would be best, as I did so in my proposed fix. > Thanks for the report. > > Yes, an issue, a unit test and a slice to fix it would be cool ;-) > > BTW, what do you propose: throw an error or use a zero time ? > > On 19 Feb 2014, at 10:27, Diego Lont <diego.lont(a)delware.nl> wrote: > >> Hi all, >> >> I probably should make an issue out of this, and follow the workflow, but I found a bug in the DateAndTime class in the method readFrom: >> >> This method comes in an infinite loop, if there is only a date specified: it tried to do aStream next while aStream peek is not a digit. And since aStream peek returns nil when the stream is at the end, this will result in an infinite loop. Here is the fixed method. >> >> Cheers, >> Diego >> >> readFrom: aStream >> "Parse and return a new DateAndTime instance from stream, >> as a Date, a Time and a TimeZone offset." >> "self readFrom: ' 2013-03-04T23:47:52.876+01:00' readStream" >> >> | offset date time | >> date := Date readFrom: aStream. >> [ aStream peek isDigit or: [ aStream atEnd ] ] whileFalse: [ aStream next ]. >> aStream atEnd >> ifTrue: [ time := Time midnight ] >> ifFalse: [ time := Time readFrom: aStream ]. >> aStream skipSeparators. >> offset := self readTimezoneOffsetFrom: aStream. >> ^ self >> year: date year >> month: date monthIndex >> day: date dayOfMonth >> hour: time hour >> minute: time minute >> second: time second >> nanoSecond: time nanoSecond >> offset: offset >> >> " '-1199-01-05T20:33:14.321-05:00' asDateAndTime >> ' 2002-05-16T17:20:45.1+01:01' asDateAndTime >> >> ' 2002-05-16T17:20:45.02+01:01' asDateAndTime >> >> ' 2002-05-16T17:20:45.003+01:01' asDateAndTime >> >> ' 2002-05-16T17:20:45.0004+01:01' asDateAndTime >> ' 2002-05-16T17:20:45.00005' asDateAndTime >> ' 2002-05-16T17:20:45.000006+01:01' asDateAndTime >> >> ' 2002-05-16T17:20:45.0000007+01:01' asDateAndTime >> ' 2002-05-16T17:20:45.00000008-01:01' asDateAndTime >> ' 2002-05-16T17:20:45.000000009+01:01' asDateAndTime >> ' 2002-05-16T17:20:45.0000000001+01:01' asDateAndTime >> >> ' 2002-05-16T17:20' asDateAndTime >> ' 2002-05-16T17:20:45' asDateAndTime >> ' 2002-05-16T17:20:45+01:57' asDateAndTime >> ' 2002-05-16T17:20:45-02:34' asDateAndTime >> ' 2002-05-16T17:20:45+00:00' asDateAndTime >> ' 1997-04-26T01:02:03+01:02:3' asDateAndTime >> " > >

Feb. 19, 2014

Versionner in pharo 3.0

by Norbert Hartl

Is anybody using Versionner in 3.0? I would be really interested in some success reports. In my case I cannot achieve much with it. I really donât get when it is creating a baseline version and when a static version. Releasing a valid baseline produces a static version that looks good but also it creates a new baseline. Why? Because creating a baseline in any of my projects lead to a bogus configuration. Versionner rewrites project dependency wrongly (projects are named after configurations and not after names I give them. loads: directives are stripped off but references in the rest of the configuration are not changed accordingly). In my current project it creates a baseline with the same version as a static version that already exists. It is a shame because it looks so good but all the funtionalities do not work in my projects except âcommit the projectâ. I hope Iâm doing something wrong but then I downloaded a fresh pharo 3.0 this morning and loaded my config and went from there. How to proceed? What kind of test case should I deliver. I think Versionner is pretty important and I should be usable in 3.0. Norbert

Feb. 19, 2014

Pharo on Raspberry Pi

by Torsten Bergmann

good news: "After some efforts, fighting with cross-compilers (cross assemblers) Jean-Baptiste Arnaud finally fixed the PharoS bug on Raspbian and now Pharo runs totally on Raspberry. Well done JB." see [1] and some advertising [2]. [1] http://pharoweekly.wordpress.com/2014/02/19/raspberrypi/ [2] http://www.dzone.com/links/pharo_runs_totally_on_raspberry.html

Feb. 19, 2014

Re: [Pharo-dev] RFB "fixed" for pharo 3.0

by Sebastian Sastre

great :D thanks for that! I'll certainly use it sebastian o/ > On 19/02/2014, at 07:50, Norbert Hartl <norbert(a)hartl.name> wrote: > > On my way to use pharo 3.0 in deployment I noticed RFB is not working in pharo 3.0. I examined the problem and find _a_ cause for it. I donât know enough about keyboard handling so I donât know if this workaround is good or bad. At least I can use RFB in 3.0 again meaning it works as good/bad as before. Iâve added a new version 0.61 especially for pharo 3.0. > > > Changes are in > > â > Name: RFB-NorbertHartl.42 > Author: NorbertHartl > Time: 19 February 2014, 11:36:04.43861 am > UUID: 399bd413-4fe4-43ec-9041-f95b6fb9b594 > Ancestors: RFB-MarianoMartinezPeck.41 > > Added extra key code in keyboard event so that RFB is usable in pharo 3.0. Exchanged some of the deprecations as well as this version is supposed to be used for pharo 3.0. One deprecation method is still left and that is Beeper beepPrimitive. This seems to be a problem in pharo > > â > > Norbert

Feb. 19, 2014

RFB "fixed" for pharo 3.0

by Norbert Hartl

On my way to use pharo 3.0 in deployment I noticed RFB is not working in pharo 3.0. I examined the problem and find _a_ cause for it. I donât know enough about keyboard handling so I donât know if this workaround is good or bad. At least I can use RFB in 3.0 again meaning it works as good/bad as before. Iâve added a new version 0.61 especially for pharo 3.0. Changes are in â Name: RFB-NorbertHartl.42 Author: NorbertHartl Time: 19 February 2014, 11:36:04.43861 am UUID: 399bd413-4fe4-43ec-9041-f95b6fb9b594 Ancestors: RFB-MarianoMartinezPeck.41 Added extra key code in keyboard event so that RFB is usable in pharo 3.0. Exchanged some of the deprecations as well as this version is supposed to be used for pharo 3.0. One deprecation method is still left and that is Beeper beepPrimitive. This seems to be a problem in pharo â Norbert

Feb. 19, 2014

Re: [Pharo-dev] Bug in DateAndTime class

by Sven Van Caekenberghe

Thanks for the report. Yes, an issue, a unit test and a slice to fix it would be cool ;-) BTW, what do you propose: throw an error or use a zero time ? On 19 Feb 2014, at 10:27, Diego Lont <diego.lont(a)delware.nl> wrote: > Hi all, > > I probably should make an issue out of this, and follow the workflow, but I found a bug in the DateAndTime class in the method readFrom: > > This method comes in an infinite loop, if there is only a date specified: it tried to do aStream next while aStream peek is not a digit. And since aStream peek returns nil when the stream is at the end, this will result in an infinite loop. Here is the fixed method. > > Cheers, > Diego > > readFrom: aStream > "Parse and return a new DateAndTime instance from stream, > as a Date, a Time and a TimeZone offset." > "self readFrom: ' 2013-03-04T23:47:52.876+01:00' readStream" > > | offset date time | > date := Date readFrom: aStream. > [ aStream peek isDigit or: [ aStream atEnd ] ] whileFalse: [ aStream next ]. > aStream atEnd > ifTrue: [ time := Time midnight ] > ifFalse: [ time := Time readFrom: aStream ]. > aStream skipSeparators. > offset := self readTimezoneOffsetFrom: aStream. > ^ self > year: date year > month: date monthIndex > day: date dayOfMonth > hour: time hour > minute: time minute > second: time second > nanoSecond: time nanoSecond > offset: offset > > " '-1199-01-05T20:33:14.321-05:00' asDateAndTime > ' 2002-05-16T17:20:45.1+01:01' asDateAndTime > > ' 2002-05-16T17:20:45.02+01:01' asDateAndTime > > ' 2002-05-16T17:20:45.003+01:01' asDateAndTime > > ' 2002-05-16T17:20:45.0004+01:01' asDateAndTime > ' 2002-05-16T17:20:45.00005' asDateAndTime > ' 2002-05-16T17:20:45.000006+01:01' asDateAndTime > > ' 2002-05-16T17:20:45.0000007+01:01' asDateAndTime > ' 2002-05-16T17:20:45.00000008-01:01' asDateAndTime > ' 2002-05-16T17:20:45.000000009+01:01' asDateAndTime > ' 2002-05-16T17:20:45.0000000001+01:01' asDateAndTime > > ' 2002-05-16T17:20' asDateAndTime > ' 2002-05-16T17:20:45' asDateAndTime > ' 2002-05-16T17:20:45+01:57' asDateAndTime > ' 2002-05-16T17:20:45-02:34' asDateAndTime > ' 2002-05-16T17:20:45+00:00' asDateAndTime > ' 1997-04-26T01:02:03+01:02:3' asDateAndTime > "

Feb. 19, 2014