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

Bug in DateAndTime class

by Diego Lont

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

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

by Eliot Miranda

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? > > > 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

Test for the string class available on SmalltalkHub

by Daniela Meneses

Hi to all, I'm writing missing test for the String class methods to improve the test coverage. I will commit my changes in this project at SmalltalkHub: http://smalltalkhub.com/#!/~DanielaMeneses/ImprovingStringAPI Feel free to take a look. Any feedback will be really welcome and useful. :D -- Cheers, Daniela

Feb. 18, 2014

Re: [Pharo-dev] Desktop Apps with Pharo 3

by Torsten Bergmann

Hi Noury, You can implement a custom world menu to replace the existing one, see my post here for a description: http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/032696.… You implement an own world menu by using a pragma and then switching to it. Ideally you have a secret key combination to switch between dev mode vs. runtime mode. Often it is a good idea to keep dev tools in end user apps - they can help you fixing a problem. So if size does not matter you can even use Unit tests to check that the environments fit the requirements for the app. Also check out the ImageCleaner, #cleanUpForProduction methods and friends. Regarding window size you can (for Windows) load my "OSWindows" package from config browser. There you can evaluate WinWindow pharoWindow moveWindowX: 10 y: 10 width: 400 height: 400 or WinWindow pharoWindow centerOnDesktop The idea of the OS package is to provide similar API wrappers for other OS platforms (like X-Windows/Unix or Mac) and the later add a common layer on top of it. Currently I only started with Windows since the Win32 API is the one that I know best. Feel free to motivate your students to help here, although it requires some NativeBoost knowledge. Also note the VistaCursors package in config browser - it shows you how to change cursors. This is often very handy for Games with custom cursors. Note that the size of the cursor can be very large if you like (as the Windows VM supports this, see an example here: [1] http://forum.world.st/New-Window-VM-Closures-FT2Plugin-Large-Cursors-td1067… I'm not sure for other platforms, just try it. You can also provide an update mechanism for an application, similar to the one Pharo uses. (loading packages via scripts, ...) You can also use: http://smalltalkhub.com/#!/~hernan/ApplicationUpdater You can also build a custom VM with an own icon and an installer file. I already described all this here: http://lists.gforge.inria.fr/pipermail/pharo-project/2009-May/008774.html Hope this gives you some ideas what could be done. Possibilities are endless... Thanks Torsten > Gesendet: Dienstag, 18. Februar 2014 um 17:26 Uhr > Von: "Noury Bouraqadi" <bouraqadi(a)gmail.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: [Pharo-dev] Desktop Apps with Pharo 3 > > Hi, > > For my Pharo Lecture I want to show students how to make a desktop app in Pharo 3.0 (Yes I'm using a Beta for my lecture, because Pharo 3 is cool :-) > > - I wonder if there are any new cool solution to strip out dev tools or at least lock the world menu? > > - Is there any way to set the OS window size other than simply turning it full screen? > > Thanks for your help, > Noury > Ecole des Mines de Douai > http://car.mines-douai.fr/noury > -- > > > > > Afin de contribuer au respect de l'environnement, > merci de n'imprimer ce courriel qu'en cas de necessite > > Please consider the environment before you print > > > > >

Feb. 18, 2014

Re: [Pharo-dev] Desktop Apps with Pharo 3

by Benjamin

On 18 Feb 2014, at 17:26, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > Hi, > > For my Pharo Lecture I want to show students how to make a desktop app in Pharo 3.0 (Yes I'm using a Beta for my lecture, because Pharo 3 is cool :-) > > - I wonder if there are any new cool solution to strip out dev tools or at least lock the world menu? To prevent the current user to open debuggers: Smalltalk tools userManager currentUser permissions canDebug: false. (pay attention to not prevent yourself to execute code :P) > > - Is there any way to set the OS window size other than simply turning it full screen? DisplayScreen hostWindowSize: ext Ben

Feb. 18, 2014

Re: [Pharo-dev] ./pharo .st argument and quit/no quit

by Camillo Bruni

> 1. Itâs worth mention that for starting a server image you can also install/hook to the #startUp: message in the right class with the benefit of not relying in an external script that might generate a problem not tested by the image builder or CI environment (which is what Iâm doing BTW) Can you precise what you mean by image builder / CI environment? > 2. it currently doesnât work. You can send an .st script alright and the save will be ignored (so you have to do that in two commands not one) Yes, I wanted to tell you that you cannot execute multiple commands at once. I think that is your original cause of errors (note this is partially document in the --help). Additionally, yes, the current CLI is very permissive, aka trailing arguments are just ignored and not reported. > 3. You donât have a server if you donât have its image prepared first. So, to be âreasonable" you have to (a) break the flow of the experience and (b) break the consistency with the default script behaviour. I don't understand what you mean here. If you run a script, you can control everything in there: - installing sofware - saving the image - quiting the image So technically you don't need the save command or anything, you rely on Pharo. The other option is to rely on several separate external commands, which will give you a more bash-like behavior. Typically this is what we do on jenkins to avoid the tedious task to maintain external scripts: - install new software with the #configuration command - save the image with a different name - start the server using the #eval command > Both at the same time. If you want to decree that the current behaviour is reasonable you have to do both: disregard the flow of the experience and the consistency of the pharo script-ish default behaviour. But that only after you fix the bug

Feb. 18, 2014

Re: [Pharo-dev] ./pharo .st argument and quit/no quit

by Sebastian Sastre

On Feb 18, 2014, at 12:02 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > As far as I see it, you use the two in distinct cases: > - save alone is exclusively used for copying an image. There is no point in no quitting in this case. thatâs okay > - execution+save is used either to start a server process (hence noquit is desired), or to setup an image (hence, quit is desired). I think favoring the server process is possibly the more common case. On the other hand, you are right in that it is not uniform with respect to the first case, but I think it is not unreasonable. > ok, here is why this smells like a Smalltalk Gremlin to me: 1. Itâs worth mention that for starting a server image you can also install/hook to the #startUp: message in the right class with the benefit of not relying in an external script that might generate a problem not tested by the image builder or CI environment (which is what Iâm doing BTW) 2. it currently doesnât work. You can send an .st script alright and the save will be ignored (so you have to do that in two commands not one) 3. You donât have a server if you donât have its image prepared first. So, to be âreasonable" you have to (a) break the flow of the experience and (b) break the consistency with the default script behaviour. Both at the same time. If you want to decree that the current behaviour is reasonable you have to do both: disregard the flow of the experience and the consistency of the pharo script-ish default behaviour. But that only after you fix the bug soâ¦ sebastian o/

Feb. 18, 2014

Desktop Apps with Pharo 3

by Noury Bouraqadi

Hi, For my Pharo Lecture I want to show students how to make a desktop app in Pharo 3.0 (Yes I'm using a Beta for my lecture, because Pharo 3 is cool :-) - I wonder if there are any new cool solution to strip out dev tools or at least lock the world menu? - Is there any way to set the OS window size other than simply turning it full screen? Thanks for your help, Noury Ecole des Mines de Douai http://car.mines-douai.fr/noury -- Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite Please consider the environment before you print

Feb. 18, 2014

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

by Stefan Marr

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. > > 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/

Feb. 18, 2014

Re: [Pharo-dev] ./pharo .st argument and quit/no quit

by Tudor Girba

As far as I see it, you use the two in distinct cases: - save alone is exclusively used for copying an image. There is no point in no quitting in this case. - execution+save is used either to start a server process (hence noquit is desired), or to setup an image (hence, quit is desired). I think favoring the server process is possibly the more common case. On the other hand, you are right in that it is not uniform with respect to the first case, but I think it is not unreasonable. Doru On Tue, Feb 18, 2014 at 3:55 PM, Sebastian Sastre < sebastian(a)flowingconcept.com> wrote: > true Tudor. > > Do you know why the default behaviour is inverted for that case? > > sebastian <https://about.me/sebastianconcept> > > o/ > > > > > > On Feb 18, 2014, at 11:47 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > You can find the answer to your question in the class comment: > > Usage: st [--help] [ --quit ] <FILE> > --help list this help message > --quit if specified, the image exits without saving after evaluating > FILE > --save if specified, save the image after evaluating FILE > <FILE> a file containing valid Pharo expressions > > Documentation: > The ST command line handler runs Pharo code stored in a file without > quiting. > > Example: > > pharo Pharo.image st code.st > # By default files ending in .st are recognized and evaluated > pharo Pharo.image code.st > > Doru > > > > On Tue, Feb 18, 2014 at 3:27 PM, Sebastian Sastre < > sebastian(a)flowingconcept.com> wrote: > >> Hi there, >> >> can someone clarify this for me? >> >> lets say you execute in the terminal: >> >> pharo-vm-nox some.image save awesome.image --delete-old >> >> it starts, saves the image and deletes the old one and quits returning >> control to terminal >> >> but if you do: >> >> pharo-vm-nox some.image ImageBuilder.st save awesome.image --delete-old >> >> it stays forever open >> >> I was taking a look at this but what is 'quit' option? can someone >> explain the behaviour of this please? >> >> STCommandLineHandler>>end >> | quit | >> >> quit := self commandLine hasOption: 'quit'. >> >> (self commandLine hasOption: 'save') >> ifTrue: [ Smalltalk snapshot: true andQuit: quit ]. >> >> quit >> ifTrue: [ self exitSuccess ]. >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 18, 2014