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

Re: [Pharo-project] Crash dump report

by StÃ©phane Ducasse

On Nov 12, 2012, at 9:32 PM, Sebastian Sastre wrote: > sure Stef. > >> Did you try with the VM with the new semaphores? > not sure. The method below answers this question? > >> and without the new semaphores handling? > again, now sure. > >> In the two cases the primitives used looks different. > What should I look? sorry I was unclear. I look at the log and at the end you have recently invoked primitives. >> Could you also provide a size of the image? > it's a 53MB image but in RAM so it does not look like large. > at the moment of the crash we don't know (we wanted to know but we didn't catched it in fraganti) > >> If the crash reproducible? > in development in OS X no it doesn't (same data). > > in production, since we started the app with the StackVM, we are having uninterrupted uptime (so far and countingâ¦) We should probably see if igor/esteban can have a look. What you are saying is that it would be more a problem on linux. > > sebastian > > o/ > > > Pharo1.4 > Latest update: #14459 > > VirtualMachine>>maxExternalSemaphores: aSize > "This method should never be called as result of normal program > execution. If it is however, handle it differently: > - In development, signal an error to promt user to set a bigger size > at startup immediately. > - In production, accept the cost of potentially unhandled interrupts, > but log the action for later review. > > See comment in maxExternalObjectsSilently: why this behaviour is > desirable, " > "Can't find a place where development/production is decided. > Suggest Smalltalk image inProduction, but use an overridable temp > meanwhile. " > | inProduction | > self maxExternalSemaphores > ifNil: [^ 0]. > inProduction := true. > ^ inProduction > ifTrue: [self maxExternalSemaphoresSilently: aSize. > self crTrace: 'WARNING: Had to increase size of semaphore signal handling table due to many external objects concurrently in use'; > crTrace: 'You should increase this size at startup using #maxExternalObjectsSilently:'; > crTrace: 'Current table size: ' , self maxExternalSemaphores printString] > ifFalse: ["Smalltalk image" > self error: 'Not enough space for external objects, set a larger size at startup!' > "Smalltalk image"] > > > > > > > > > On Nov 12, 2012, at 6:22 PM, StÃ©phane Ducasse wrote: > >> thanks a lot for sharing that with us. >> Did you try with the VM with the new semaphores? and without the new semaphores handling? >> In the two cases the primitives used looks different. >> Could you also provide a size of the image? >> If the crash reproducible? >> Stef >> >> On Nov 12, 2012, at 8:12 PM, Sebastian Sastre 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 >>> >>> <dump.zip> >>> >>> sebastian >>> >>> o/ >>> >>> >>> >>> >>> >> >> >

Nov. 12, 2012

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

by Esteban Lorenzano

yeah but future does not means "right in the corner", just a bit more time :) On Nov 12, 2012, at 9:57 PM, Sebastian Nozzi <sebnozzi(a)gmail.com> wrote: > UI builder? Cool, this is getting better and better... :-) > > 2012/11/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Yes. >> So for now you simply used plain polymorph. >> In the future we will have a UI builder. >> >> >> Stef >

Nov. 12, 2012

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

by Sebastian Nozzi

Since you mention it, yes. I think (but not 100% sure) that I had the case that I chose all the relevant changes to recover, but still I got the error message about a class not existing. The class creation event was not there (in the changes). It might have been an obscure case, maybe I deleted the class, and then renamed an existing one to the name of the deleted class... Something along the lines... But it's not because of that case that I wrote this utility. For me, it's just a matter of preference. I prefer not to sort through the changes, and file-in the categories I was working for. If I *do* need "recover lost changes", I know it's there. And of course this tool is only limited to the categories specified, whereas the "recover lost changes" deals with system-wide changes. Regards, Sebastian 2012/11/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > thanks > Now do you have a case where the categories get lost (because they should be saved in the change file) > And we may broke something. > Which version are you using? > > Stef

Nov. 12, 2012

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

by Esteban Lorenzano

+1 On Nov 12, 2012, at 9:57 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > 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. > > Cheers, > Doru > > > On 12 Nov 2012, at 15:56, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> You won I put a filter markdown to thrash on my mail sadly. >> >> >> On Nov 12, 2012, at 3:11 PM, Camillo Bruni wrote: >> >>>>> It depends at which level. >>>>> Can you tag on word in markdown to have bold, italic, index? >>> >>> stef, I already explained you that at least 4 times! Plus I gave you the solutions, >>> the only thing I don't have is the time to complete the Markdown parser! >>> >>>>> If I would not have written 350 pages of seaside book with pier it would be a different story but >>>>> so far pier syntax is good for doing everything: html, latex, even markdown. >>>> >>>> In Markdown, it is *italic* or _italic_ and **bold** and __bold__. >>>> >>>> Now for index entries, I don't know exactly - making an automatic index is a special post process function anyway. >>>> I think you could do something like [ReadStream][index-entry]s are objects that you can read bytes or characters from. >>>> >>>> Making a book from several independent source files is quite a job that requires custom programming. It would be very cool if we could do all that in Smalltalk, using a good Markdown parser and a cool object representation. >>>> >>>> I have nothing against Pier, but it is something that only exists in our niche world, not in the larger world out there. >>> >>> my words! >>> >>> So we already had a Markdown / HelpSystem crossover for NativeBoost / ASMJit where we injected >>> custom URLs to add method and class links, that worked pretty well. So I assume it will be >>> not that much work on top to get section links ready. >>> >>> Something like book://section/subsection is very easy to do, a bit verbose maybe but very >>> consistent. >>> >>> >>> so, please support: >>> https://github.com/dh83/PPMarkdown >>> http://ss3.gemstone.com/ss/petitmarkdown.html/ >> >> > > -- > www.tudorgirba.com > > "Every thing should have the right to be different." > > > >

Nov. 12, 2012

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

by Sebastian Nozzi

UI builder? Cool, this is getting better and better... :-) 2012/11/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Yes. > So for now you simply used plain polymorph. > In the future we will have a UI builder. > > > Stef

Nov. 12, 2012

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

by Tudor Girba

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. Cheers, Doru On 12 Nov 2012, at 15:56, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > You won I put a filter markdown to thrash on my mail sadly. > > > On Nov 12, 2012, at 3:11 PM, Camillo Bruni wrote: > >>>> It depends at which level. >>>> Can you tag on word in markdown to have bold, italic, index? >> >> stef, I already explained you that at least 4 times! Plus I gave you the solutions, >> the only thing I don't have is the time to complete the Markdown parser! >> >>>> If I would not have written 350 pages of seaside book with pier it would be a different story but >>>> so far pier syntax is good for doing everything: html, latex, even markdown. >>> >>> In Markdown, it is *italic* or _italic_ and **bold** and __bold__. >>> >>> Now for index entries, I don't know exactly - making an automatic index is a special post process function anyway. >>> I think you could do something like [ReadStream][index-entry]s are objects that you can read bytes or characters from. >>> >>> Making a book from several independent source files is quite a job that requires custom programming. It would be very cool if we could do all that in Smalltalk, using a good Markdown parser and a cool object representation. >>> >>> I have nothing against Pier, but it is something that only exists in our niche world, not in the larger world out there. >> >> my words! >> >> So we already had a Markdown / HelpSystem crossover for NativeBoost / ASMJit where we injected >> custom URLs to add method and class links, that worked pretty well. So I assume it will be >> not that much work on top to get section links ready. >> >> Something like book://section/subsection is very easy to do, a bit verbose maybe but very >> consistent. >> >> >> so, please support: >> https://github.com/dh83/PPMarkdown >> http://ss3.gemstone.com/ss/petitmarkdown.html/ > > -- www.tudorgirba.com "Every thing should have the right to be different."

Nov. 12, 2012

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

by Sebastian Nozzi

2012/11/12 Damien Cassou <damien.cassou(a)gmail.com>: > it's a backup! You probably never need any backup... until you do :-). Exactly! ;-) > In a perfect world Pharo would be perfect, never crash and never loose > any data. To be fair, I have not had a VM crash in quite some time. What I do manage to archieve is to make the image unresponsive (either by halting where I am not supposed to, or introduce delays/infinite-recursions in the UI thread, etc.). Then I have to kill the VM. It is sad having to kill the VM, not being able to rescue your unsaved work. But Mariano is right, and I *am* aware of the "recover lost changes" functionality (it was not always the case though), and I would like to address his comments/concerns... > On Mon, Nov 12, 2012 at 8:42 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > Now, I would really like to understand if this is a real need of a new tool > or a demonstration that the current tools need some improvements. As you may > know, we always have the .changes and therefore we can tools to recover lost > data from there. We have the change sorter, the "recover lost code", etc. We > are even able to load the .changes in another image. > So...my question is, what is the actual problem/limitations with those which > are "solved" with this new tool?? or in other words, why do we need this new > tool? should we improve the already existing tools instead? Mariano, you raise very valid points and questions. I know about the "recover lost code" functionality, and have had to use it myself a couple of times already. And was very glad and relieved after the fact! :-) When I post this, I don't do it to question or challenge core Pharo functionalities. I do it as a "user" sharing a solution that I programmed for myself, for my own uses, and hoping it might be useful for somebody else. Maybe it *is* confusing if I post something like this on the "pharo-project" mailing list. I apologize for this. 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. For one, I find it tedious to have to sort through do-its that just *might* be important, or maybe not... It takes too long, it is something that demands too much concentration from me, and a process where I can do many things wrong (what happens if I forget a couple of methods? can I be sure I didn't forget anything). And then there are the renames, class deletions, etc. On top of that, I think that not all might land on the ".changes"... I had the case where a class creation was not there... Maybe it was a class rename, or something like that. Me, if I have to decide between sorting through a long list of changes, or just doing "file-in" from a couple of files and be done in seconds, I take the latter approach ;-) Again, this is a solution I hacked for me, and am just sharing with the world :-). It's not meant as a "reconver lost changes" replacement... But I understand your concerns, and am glad you raised them. Cheers, Sebastian

Nov. 12, 2012

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

by Mariano Martinez Peck

On Mon, Nov 12, 2012 at 8:53 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > On Mon, Nov 12, 2012 at 8:42 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > So...my question is, what is the actual problem/limitations with those > which > > are "solved" with this new tool?? or in other words, why do we need this > new > > tool? should we improve the already existing tools instead? > > it's a backup! You probably never need any backup... until you do :-). > In a perfect world Pharo would be perfect, never crash and never loose > any data. > Yes, but .changes is already a backup, so my questions are still valid ;) > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > > -- Mariano http://marianopeck.wordpress.com

Nov. 12, 2012

Re: [Pharo-project] Crash dump report

by Sebastian Sastre

sure Stef. > Did you try with the VM with the new semaphores? not sure. The method below answers this question? > and without the new semaphores handling? again, now sure. > In the two cases the primitives used looks different. What should I look? > Could you also provide a size of the image? it's a 53MB image but in RAM at the moment of the crash we don't know (we wanted to know but we didn't catched it in fraganti) > If the crash reproducible? in development in OS X no it doesn't (same data). in production, since we started the app with the StackVM, we are having uninterrupted uptime (so far and counting...) sebastian o/ Pharo1.4 Latest update: #14459 VirtualMachine>>maxExternalSemaphores: aSize "This method should never be called as result of normal program execution. If it is however, handle it differently: - In development, signal an error to promt user to set a bigger size at startup immediately. - In production, accept the cost of potentially unhandled interrupts, but log the action for later review. See comment in maxExternalObjectsSilently: why this behaviour is desirable, " "Can't find a place where development/production is decided. Suggest Smalltalk image inProduction, but use an overridable temp meanwhile. " | inProduction | self maxExternalSemaphores ifNil: [^ 0]. inProduction := true. ^ inProduction ifTrue: [self maxExternalSemaphoresSilently: aSize. self crTrace: 'WARNING: Had to increase size of semaphore signal handling table due to many external objects concurrently in use'; crTrace: 'You should increase this size at startup using #maxExternalObjectsSilently:'; crTrace: 'Current table size: ' , self maxExternalSemaphores printString] ifFalse: ["Smalltalk image" self error: 'Not enough space for external objects, set a larger size at startup!' "Smalltalk image"] On Nov 12, 2012, at 6:22 PM, StÃ©phane Ducasse wrote: > thanks a lot for sharing that with us. > Did you try with the VM with the new semaphores? and without the new semaphores handling? > In the two cases the primitives used looks different. > Could you also provide a size of the image? > If the crash reproducible? > Stef > > On Nov 12, 2012, at 8:12 PM, Sebastian Sastre 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 >> >> <dump.zip> >> >> sebastian >> >> o/ >> >> >> >> >> > >

Nov. 12, 2012

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

by StÃ©phane Ducasse

On Nov 12, 2012, at 9:19 PM, Sebastian Nozzi wrote: > It seems that I *was* using Spec after all :-) Only I didn't know it... > At least I think so, since I defined the UI programmatically... > > I used information from here: > > http://book.pharo-project.org/book/LanguageAndLibraries/GUI/PolymorphTutori… > > and here: > > http://www.pharocasts.com/2011/02/pharo-gui-with-polymorph.html > > And if I understand correctly Spec and Polymorph don't compare, > because Spec "uses" Polymorph (right?). Yes. So for now you simply used plain polymorph. In the future we will have a UI builder. Stef

Nov. 12, 2012