November 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Crash dump report

by Sven Van Caekenberghe

These situations are very hard to debug by outsiders, for the community to help we need a reproduceable case that does not depend on internal or private services. The stacktrace is not exceptional as far as I can see: it is trying to read a response until EOF, after a POST. It is quite strange that it would work with the stack VM, since the same Smalltalk code is then running, using the same primitives. Maybe the other VM just postpones/changes the way it fails. Running out of semaphores is a resource management problem, caused directly or indirectly from certain usage patterns. Again, see the first sentence. I would advice running units and/or stress tests on the server or on a Linux VM with UI on your Mac. Bughunts are never easyâ¦ On 13 Nov 2012, at 00:33, Igor Stasenko <siguctua(a)gmail.com> wrote: > yeah the dumps are really strange.. > seems like most of the times crashing at this point: > > 0xffc05bd8 M ZnChunkedReadStream>next -613198972: a(n) ZnChunkedReadStream > 0xffc05bfc M ZnUTF8Encoder>nextFromStream: -613185216: a(n) ZnUTF8Encoder > 0xffc05c30 M [] in ZnStringEntity>readUpToEndFrom: -613186408: a(n) > ZnStringEntity > 0xffc1333c M BlockClosure>on:do: -613184868: a(n) BlockClosure > 0xffc1336c M [] in ZnStringEntity>readUpToEndFrom: -613186408: a(n) > ZnStringEntity > 0xffc1338c M String class(SequenceableCollection > class)>new:streamContents: -679940384: a(n) String class > 0xffc133ac M String class(SequenceableCollection > class)>streamContents: -679940384: a(n) String class > 0xffc133d8 M ZnStringEntity>readUpToEndFrom: -613186408: a(n) ZnStringEntity > 0xffc133f4 M ZnStringEntity>readFrom: -613186408: a(n) ZnStringEntity > 0xffc13414 M ZnEntity class>readFrom:usingType:andLength: -678925448: > a(n) ZnEntity class > 0xffc13440 M ZnEntityReader>readFrom:usingType:andLength: -613217204: > a(n) ZnEntityReader > 0xffc13474 M ZnEntityReader>readEntityFromStream -613217204: a(n) ZnEntityReader > 0xffc13490 M ZnEntityReader>readEntity -613217204: a(n) ZnEntityReader > 0xffc134ac M ZnResponse(ZnMessage)>readEntityFrom: -614400344: a(n) ZnResponse > 0xffc134c8 M ZnResponse>readEntityFrom: -614400344: a(n) ZnResponse > > On 12 November 2012 16:12, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >> Hi guys, >> >> I'm sorry for this news. >> >> We have a web app that's is increasingly crashing in production (on linux). >> >> In development (OS X) we couldn't reproduce >> >> We are falling back to the StackVM >> >> Here is some dump data we could get >> >> sebastian >> >> o/ > > -- > Best regards, > Igor Stasenko.

Nov. 13, 2012

Re: [Pharo-project] nonblocking stdin?

by Camillo Bruni

hmm we solved that by changing the behavior of stdin before launching the vm. so you get character by character input, otherwise stdin is only flushed on lf... see the starter script from coral. On 2012-11-13, at 10:01, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > is there a way how to use nonblocking input from stdin? I have a > simple REPL but the stdin is blocking the VM. > > | stdin input lineEnd | > > stdin := FileStream stdin ifNil: [ ^ self ]. > stdin atEnd ifTrue: [ ^ self ]. > > [ > lineEnd := false. > FileStream stdout nextPutAll: '> '. > input := String streamContents: [:s| > [ stdin atEnd or: [lineEnd] ] whileFalse: [ > stdin next ifNotNilDo: [:char| > char = Character lf ifTrue: [lineEnd := true]. > s nextPut: char ]]]. > > [ FileStream stdout print: (Compiler evaluate: input); lf ] > ifError: [:error | FileStream stdout nextPutAll: 'ERROR: ', > error asString; lf]. > > Processor yield. > ] repeat > > Cheers, > -- Pavel >

Nov. 13, 2012

[Pharo-project] nonblocking stdin?

by Pavel Krivanek

Hi, is there a way how to use nonblocking input from stdin? I have a simple REPL but the stdin is blocking the VM. | stdin input lineEnd | stdin := FileStream stdin ifNil: [ ^ self ]. stdin atEnd ifTrue: [ ^ self ]. [ lineEnd := false. FileStream stdout nextPutAll: '> '. input := String streamContents: [:s| [ stdin atEnd or: [lineEnd] ] whileFalse: [ stdin next ifNotNilDo: [:char| char = Character lf ifTrue: [lineEnd := true]. s nextPut: char ]]]. [ FileStream stdout print: (Compiler evaluate: input); lf ] ifError: [:error | FileStream stdout nextPutAll: 'ERROR: ', error asString; lf]. Processor yield. ] repeat Cheers, -- Pavel

Nov. 13, 2012

Re: [Pharo-project] OSProcess in Pharo 2.0

by Peter H. Meadows

Is OSProcess still the best/correct way? I've been using it in 2.0. Seems to work. load: MCHttpRepository location: 'http://smalltalkhub.com/mc/dh83/fisleg/main' user: '' password: '' then do: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOSProcess'; load. (Smalltalk at: #ConfigurationOfOSProcess) project bleedingEdge load. Is the only issue updating to FileSystem, or are there other changes that are needed for Pharo 2.0? On Fri, Nov 9, 2012 at 9:35 AM, roberto.minelli(a)usi.ch <roberto.minelli(a)usi.ch> wrote: > Hi, > > I'd like to script some shell commands in Pharo 2.0. > Is there any way to do that in Pharo? It seems OSProcess class is suitable but seems it's not yet fully ported in Pharo 2.0. > > Thanks, > Roberto

Nov. 13, 2012

Re: [Pharo-project] Crash dump report

by Igor Stasenko

yeah the dumps are really strange.. seems like most of the times crashing at this point: 0xffc05bd8 M ZnChunkedReadStream>next -613198972: a(n) ZnChunkedReadStream 0xffc05bfc M ZnUTF8Encoder>nextFromStream: -613185216: a(n) ZnUTF8Encoder 0xffc05c30 M [] in ZnStringEntity>readUpToEndFrom: -613186408: a(n) ZnStringEntity 0xffc1333c M BlockClosure>on:do: -613184868: a(n) BlockClosure 0xffc1336c M [] in ZnStringEntity>readUpToEndFrom: -613186408: a(n) ZnStringEntity 0xffc1338c M String class(SequenceableCollection class)>new:streamContents: -679940384: a(n) String class 0xffc133ac M String class(SequenceableCollection class)>streamContents: -679940384: a(n) String class 0xffc133d8 M ZnStringEntity>readUpToEndFrom: -613186408: a(n) ZnStringEntity 0xffc133f4 M ZnStringEntity>readFrom: -613186408: a(n) ZnStringEntity 0xffc13414 M ZnEntity class>readFrom:usingType:andLength: -678925448: a(n) ZnEntity class 0xffc13440 M ZnEntityReader>readFrom:usingType:andLength: -613217204: a(n) ZnEntityReader 0xffc13474 M ZnEntityReader>readEntityFromStream -613217204: a(n) ZnEntityReader 0xffc13490 M ZnEntityReader>readEntity -613217204: a(n) ZnEntityReader 0xffc134ac M ZnResponse(ZnMessage)>readEntityFrom: -614400344: a(n) ZnResponse 0xffc134c8 M ZnResponse>readEntityFrom: -614400344: a(n) ZnResponse On 12 November 2012 16:12, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > Hi guys, > > I'm sorry for this news. > > We have a web app that's is increasingly crashing in production (on linux). > > In development (OS X) we couldn't reproduce > > We are falling back to the StackVM > > Here is some dump data we could get > > > > sebastian > > o/ > > > > > > -- Best regards, Igor Stasenko.

Nov. 12, 2012

[Pharo-project] [update 2.0] #20390

by Marcus Denker

20390 ----- Issue 6912: #fancyText:font:color: has no senders, and is in strange place (AlignmentMorph) http://code.google.com/p/pharo/issues/detail?id=6912 Issue 6883: Type Class refactoring http://code.google.com/p/pharo/issues/detail?id=6883 Issue 6947: Small cleanup for DebuggerMethodMap http://code.google.com/p/pharo/issues/detail?id=6947 Diff information: http://ss3.gemstone.com/ss/Pharo20/NautilusRefactoring-MarcusDenker.57.diff http://ss3.gemstone.com/ss/Pharo20/Morphic-MarcusDenker.1276.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1240.diff -- Marcus Denker -- http://marcusdenker.de

Nov. 12, 2012

Re: [Pharo-project] [ANN] Pharo Online Help 1.0

by Camillo Bruni

> >> Hi, >> >> I completely agree that the PIer syntax is rather niche these days, but we should not confuse the PIer syntax with the Pier model. I think that it would be beneficial to capitalize on this model (and all the infrastructure built on top of it) and simply create a Markdown support. yes, that makes perfectly sense!

Nov. 12, 2012

Re: [Pharo-project] [Pharo-users] CategorySaver

by Damien Cassou

On Mon, Nov 12, 2012 at 9:51 PM, Sebastian Nozzi <sebnozzi(a)gmail.com> wrote: > Now, having said this, let me tell you that *I* (me) am not always > happy with the "recover lost changes" way of recovering my changes. People are working on how to improve this situation, you are not alone :-). > As I said, I think I should not have posted on "pharo project". I don't know about that. Many community announcements are made here and nobody complained (I certainly didn't as I think your email was totally justified). So don't worry, everything is fine :-) -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Nov. 12, 2012

Re: [Pharo-project] [Pharo-users] CategorySaver

by Sebastian Nozzi

2012/11/12 Fernando Olivero <fernando.olivero(a)usi.ch>: > Sebastian, thanks for sharing your code and thoughts. Hey, you're welcome. > Maybe what Mariano was implying is that you already have the data for the > backup in the changes, and having yet another mechanism for that adds > complexity to the system. As I said, I think I should not have posted on "pharo project". I didn't mean this as a contribution to the project per se, but to the community (as a user, to the users). I am not suggesting for a second that it should be part of the system. It's something I coded for me, and wanted to share. And of course, everyone is free *not* to use it ;-) > I think is a good idea, but too focused on the categories you choose up > front..and not on those actual changes you perform on the system. I would like to know how to ask the system what classes did I change. But the only things I found took minutes to execute (asking every class for its authors, or something like that). Very brute-fore. I'm sure there is a better approach I am not aware of. > Which is why the recovering from the changes file is better. I don't see it as "which one is better". I am honoured that this was interpreted as a serious theoretical "inclusion" as a Pharo feature, with shortcomings or not :-) > Dont worry, the image crashes every now and then to all of us! fortunately > since Pharo1.0, less and less every day... Yes, I also noticed! The VM is very robust nowadays! > Regarding the UI, you should check out Spec, by Benjamin and Stef. It's > easier to create morphs programmatically than with the raw Polymorph. I think I actually used Spec, but not sure... > And also check out Glamour, the ones used in Moose. Glamour is for building tools, right...? Could I have used it...? > Saludos, > Fernando Saludos tambiÃ©n! ;-) Sebastian

Nov. 12, 2012

Re: [Pharo-project] [Pharo-users] CategorySaver

by StÃ©phane Ducasse

On Nov 12, 2012, at 9:51 PM, Sebastian Nozzi wrote: > Now, having said this, let me tell you that *I* (me) am not always > happy with the "recover lost changes" way of recovering my changes. Me too. Stef

Nov. 12, 2012