- Pharo-dev - lists.pharo.org

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

by Damien Cassou

On Wed, Feb 19, 2014 at 3:43 PM, <btc(a)openinworld.com> wrote: > Also I have seen discussion that > assert: a equals: b > is preferred over > assert: ( a = b) yes, because you get better error messages. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Feb. 19, 2014

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

by Damien Cassou

On Tue, Feb 18, 2014 at 5:26 PM, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > 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 :-) https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Feb. 19, 2014

Re: [Pharo-dev] Connection closed while waiting for data in bootstrapped image

by Sven Van Caekenberghe

Weird indeed! This works as well. In one console: # ./pharo PharoKernel.image eval 'Socket newTCP listenOn: 8484; waitForConnectionFor: 60; receiveData' 'Hi there!! ' In another: # nc localhost 8484 Hi there!! Strange, strange, strange On 18 Feb 2014, at 15:23, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > They seem to be ok. > > I tried to look at the sockets during waiting in other thread and signal their semaphores but no change. > Socket loopbackTest WORKS. > > -- Pavel > > > 2014-02-17 11:18 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: > ExternalSemaphores table may be not well initialized? I can help having a look this afternoon :) > > > On Mon, Feb 17, 2014 at 11:11 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Pavel, > > I just tried on a machine of mine. > > I changed testNetwork.st to > > Transcript show: (ZnClient new logToTranscript; get: 'http://zn.stfx.eu/zn/numbers.txt'); cr. > > That way you get a bit more progress info. As I suspected the request is written and the failure is while reading the response. I tried connecting to a local Zinc server which confirmed this as well: the request comes in on the server and it writes the response. > > This is the output now: > > root@stfx:~# ./pharo PharoKernel.image testNetwork.st > > 2014-02-17 10:00:59 463573 I Wrote a ZnRequest(GET /random) > 2014-02-17 10:00:59 463573 D Sent headers > > User-Agent: Zinc HTTP Components 1.0 > > Accept: */* > > Host: localhost:1701 > > > =============================================================================== > Notice: Errors in script loaded from /root/testNetwork.st > =============================================================================== > Errors in script loaded from /root/testNetwork.st > ==== Startup Error: ConnectionClosed: Connection closed while waiting for data. > Socket>>waitForDataFor: in Block: [ ConnectionClosed signal: 'Connection closed whil...etc... > Socket>>waitForDataFor:ifClosed:ifTimedOut: > Socket>>waitForDataFor: > Socket>>receiveDataSignallingTimeout:into:startingAt: > SocketStream>>receiveData > SocketStream>>next > ZnLineReader>>processNext > ZnLineReader>>nextLine > ZnStatusLine>>readFrom: > ZnStatusLine class>>readFrom: > ZnResponse>>readHeaderFrom: > ZnResponse(ZnMessage)>>readFrom: > ZnResponse class(ZnMessage class)>>readFrom: > ZnClient>>executeRequestResponse > ZnClient>>getConnectionAndExecute in Block: [ self executeRequestResponse ] > BlockClosure>>ensure: > ZnClient>>getConnectionAndExecute > ZnClient>>executeWithRedirectsRemaining: > ZnClient>>executeWithRetriesRemaining: in Block: [ self executeWithRedirectsRemaining: self maxNumb...etc... > BlockClosure>>on:do: > ZnClient>>executeWithRetriesRemaining: > ZnClient>>executeWithTimeout in Block: [ self executeWithRetriesRemaining: self numberOfR...etc... > BlockClosure>>on:do: > ZnClient>>executeWithTimeout in Block: [ ... > ZnClient>>withTimeoutDo: in Block: [ ^ block value ] > ZnConnectionTimeout(DynamicVariable)>>value:during: in Block: > > You are using regular socket streams, which is good. For now I can't think of a reasons why the reading would fail, if I think of something, I will let you know. > > It is pretty hard to debug this way ;-) > > Sven > > On 17 Feb 2014, at 10:22, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > (NetNameResolver addressForName: 'www.esug.org') returns good value... > > > > -- Pavel > > > > > > 2014-02-17 9:32 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > > Hi, > > > > thank you for the tip. It seems that it is not directly Zinc related. But if you want something to play with, do: > > > > - load the bootstrapped image: > > https://ci.inria.fr/pharo-contribution/view/Pharo-Kernel-3.0/job/PharoKerne… > > > > ./pharo PharoKernel.image fix.st > > ./pharo PharoKernel.image loadNetwork.st > > ./pharo PharoKernel.image testNetwork.st > > > > The CI slaves revolt now so I cannot make it more comfortable :-) > > > > Cheers, > > -- Pavel > > > > > > > > > > 2014-02-16 22:58 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > Hi Pavel, > > > > On 16 Feb 2014, at 22:23, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > > > Hi Sven, > > > > > > we can successfully load network packages to the bootstrapped image but when we try to test it using: > > > > > > ZnClient new get: 'http://zn.stfx.eu/zn/numbers.txt'. > > > > > > we get "ConnectionClosed: Connection closed while waiting for data" error after few seconds. Do you have some idea, what may be wrong? Probably something is not initialized well but I have no clue what. > > > > > > Cheers, > > > -- Pavel > > > > Hard to say. I would guess that you are already on the point of waiting for a server response, so you already successfully initialised networking, resolved DNS, opened a TCP socket and wrote the request over it. On the other hand, one of those steps might not have been done right, since you get no response. > > > > Any chance of a stack trace ? Or an image ? But that would be a headless one I guess ;-) > > > > Sven > > > > > > > > > > > > > >

Feb. 19, 2014

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

by btc＠openinworld.com

Feb. 19, 2014

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