- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] petit parser longest match

by Chris Cunningham

There are several things wrong with it, actually. First, in my example, I never did actually return the longest error - I just set the location to the longest error location. Not right at all. Next, setting the stream to the position of the error on the choice is not a good idea. The problem is when you have more than 1 choice depth. So, the first choice goes down path 1, which calls another choice (eventually), which fails and resets the location to some point further on in the stream. The the rollback to the first choice seems to get fouled up and doesn't work quite right. Probably. In any case, playing with how it is storing and returning, I am getting wildly different points of where the track fails. Finally, the array at each choice doesn't necessarily pick the furthest failure. If you consider a 4 choice depth parser (which is roughly what I'm working with - parsing Java source code), the 4th choice will fail on a couple of paths, and then eventually work on one. This might then return back to the 3rd choice successfully (so no error, so no returned error from that choice) and then later fails. That particular path might be much shorter (that it made it through) than the one that failed earlier (maybe a much more complex but also more consuming path, for example). The question is what exactly are you (we) looking for. * I think we want to know what was the parsing path the best describes the source file we are parsing, and where is it failing to parse. * I would also like to know what the path was that arrived at that point (the context) so that I can decide how to either fix the parser (if it is wrong) or fix the source. So, I'm still looking for a better answer than the two I tried to provide earlier. -cbc On Wed, Nov 20, 2013 at 5:03 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > I'm not sure what you are trying to improve. It works quite well :) > > Norbert > > Am 20.11.2013 um 22:59 schrieb Chris Cunningham <cunningham.cb(a)gmail.com>: > > ehh, ignore this for now. Neither is working well enough. If I get > something working well, I'll post back. > > > On Wed, Nov 20, 2013 at 1:45 PM, Chris Cunningham <cunningham.cb(a)gmail.com > > wrote: > >> Actually, do this [the #( 0 nil ) meant it was shared with ALL choice >> parsers forever - not a good choice]. >> >> parseOn: aStream >> "This is optimized code that avoids unnecessary block activations, do not >> change. When all choices fail, the last failure is answered." >> >> | element longest | >> longest := Array with: 0 with: nil. >> 1 to: parsers size do: [ :index | >> element := (parsers at: index) >> parseOn: aStream. >> element isPetitFailure >> ifTrue: [ aStream position > longest first ifTrue: [ longest at: 1 put: >> aStream position; at: 2 put: element ] ] >> ifFalse: [ ^ element ] ]. >> aStream position: longest first. >> ^ element >> >> >> On Wed, Nov 20, 2013 at 1:35 PM, Chris Cunningham < >> cunningham.cb(a)gmail.com> wrote: >> >>> Ho about this (replacement for yours, or just replace in PPChoiceParser >>> - but it will result in different behavior for that method outside of your >>> particular parser, so beware): >>> >>> parseOn: aStream >>> "This is optimized code that avoids unnecessary block activations, do >>> not change. When all choices fail, the last failure is answered." >>> >>> | element longest | >>> longest := #( 0 nil ). >>> 1 to: parsers size do: [ :index | >>> element := (parsers at: index) >>> parseOn: aStream. >>> element isPetitFailure >>> ifTrue: [ aStream position > longest first ifTrue: [ longest at: 1 >>> put: aStream position; at: 2 put: element ] ] >>> ifFalse: [ ^ element ] ]. >>> aStream position: longest first. >>> ^ element >>> >>> I had a need for it in the past (and, just now, in fact - so minimally >>> tested just now). >>> >>> -cbc >>> >>> >>> On Wed, Nov 20, 2013 at 2:15 AM, Norbert Hartl <norbert(a)hartl.name>wrote: >>> >>>> I talked to Lukas two years ago about parsing the longest match [1]. He >>>> committed it to PetitBeta back then. Now I need it and I had a look at the >>>> current parsers but didnât find one that can do the same. Is there a parser >>>> that can do longest match? >>>> >>>> If not I would propose adding that to the default petit parser package. >>>> Lukasâ proposal back then was >>>> >>>> LongestChoiceParser>>parseOn: aStream >>>> | start element longestEnd longestElement | >>>> start := aStream position. >>>> 1 to: parsers size do: [ :index | >>>> element := (parsers at: index) >>>> parseOn: aStream. >>>> (longestEnd isNil or: [ longestEnd < aStream position ]) ifTrue: [ >>>> longestEnd := aStream position. >>>> longestElement := element ]. >>>> aStream position: start ]. >>>> aStream position: longestEnd. >>>> ^ longestElement >>>> >>>> >>>> Norbert >>>> >>>> [1] http://www.iam.unibe.ch/pipermail/moose-dev/2011-July/009365.html >>>> >>> >>> >> >

Nov. 21, 2013

Re: [Pharo-dev] Tuning Opal Optimizations

by Goubier Thierry

Le 21/11/2013 16:37, Igor Stasenko a Ã©crit : > > > > On 21 November 2013 16:30, Goubier Thierry <thierry.goubier(a)cea.fr > <mailto:thierry.goubier@cea.fr>> wrote: > > What about having a configuration with a prerequisite package > setting up options ? Or optimisation tuning in one of the preload > script of the package ? > > We already have ways to tune that; wouldn't they be better than > setting a not so clear class before instance ordering (and what if > the class itself requires that kind of tuning?). > > > i doubt that there can be universal formal solution to this. We have to > put some reasonable constraints into system, > in order to be able to have a predictable behavior during boot-loading > or bootstrapping. > Or , somehow , package should carry enough metadata to tell system , in > what order it must load things in it.. > and problem obviously is wider than just order of compilation inside a > single class, because it is just a part of bigger picture which is: > - order or class loading and initialization > > i imagine that a complete (or say, most flexible) load order control > must include class loading and class initialization e.g.: > > load: ClassA , load:ClassB, init:ClassB, init:ClassA, load:ClassC Of course, a perfect solution would be that, it would avoid seeing Undeclared stuff popping up when loading... I'd like an automatic way to load stuff so that even recursively dependent classes would not trigger any Undeclared stuff :) But, at the same time, if we have special requests, we can order them via package pre-requisites and preload scripts, isn't it? Thierry > Thierry > > Le 21/11/2013 16:15, Marcus Denker a Ã©crit : > > > On 21 Nov 2013, at 15:55, Igor Stasenko <siguctua(a)gmail.com > <mailto:siguctua@gmail.com> > <mailto:siguctua@gmail.com <mailto:siguctua@gmail.com>>> wrote: > > > > > On 21 November 2013 12:30, Marcus Denker > <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr> > <mailto:marcus.denker@inria.fr > <mailto:marcus.denker@inria.fr>__>> wrote: > > > On 21 Nov 2013, at 11:34, Sven Van Caekenberghe > <sven(a)stfx.eu <mailto:sven@stfx.eu> > <mailto:sven@stfx.eu <mailto:sven@stfx.eu>>> wrote: > > > > > On 19 Nov 2013, at 16:45, Sven Van Caekenberghe > <sven(a)stfx.eu <mailto:sven@stfx.eu> > <mailto:sven@stfx.eu <mailto:sven@stfx.eu>>> wrote: > > > >>> > >>> Yes, you can do it per class-hierarchyâ¦ you can > implement on > the class side a method to parametrize the compiler: > >>> > >>> compiler > >>> ^super compiler options: #(- > optionInlineTimesRepeat) > >> > >> Thanks, Marcus, that works just great. > > > > Marcus, > > > > Are we sure this option mechanism works when loading code > through Monticello ? > > > > Noâ¦ we should make sure that MC loads the method first. > I think it > does that for #compilerClass > already (but not sure). > > > which is still doesn't eliminates problem completely, > because nothing > prevents me from having: > > compilerClass > ^ self otherMethod > > and now in order to work, MC have to know somehow that > #otherMethod > should also be loaded first. > But i think some prioritization guarantees would be really > useful. > At least i think we can easily prioritize class-side > compilation over > instance side. > Like that, when you compiling any of instance-side method, > you know > that class side is already there (and can be used > as such in different kinds of hooks). > > > yes, we need atomic code loading. > > Marcus > > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 > <tel:%2B33%20%280%29%201%2069%2008%2032%2092> / 83 95 > > > > > -- > Best regards, > Igor Stasenko. -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Nov. 21, 2013

Re: [Pharo-dev] Is Coral still alive?

by Camillo Bruni

On 2013-11-21, at 16:36, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>>> which already exists and it's named LIMBO :) >> >> Cool! But yes, supporting beyond Mac will be a must. Out of curiosity, why >> does it require a plugin? It has seemed to me that one of the purposes of NB >> is to bring code into the image, and out of the VM... In short, you have to execute fork + subcommand in a single C function, which is currently not that easy possible in NativeBoost.

Nov. 21, 2013

Re: [Pharo-dev] Tuning Opal Optimizations

by Igor Stasenko

On 21 November 2013 16:30, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > What about having a configuration with a prerequisite package setting up > options ? Or optimisation tuning in one of the preload script of the > package ? > > We already have ways to tune that; wouldn't they be better than setting a > not so clear class before instance ordering (and what if the class itself > requires that kind of tuning?). > > i doubt that there can be universal formal solution to this. We have to put some reasonable constraints into system, in order to be able to have a predictable behavior during boot-loading or bootstrapping. Or , somehow , package should carry enough metadata to tell system , in what order it must load things in it.. and problem obviously is wider than just order of compilation inside a single class, because it is just a part of bigger picture which is: - order or class loading and initialization i imagine that a complete (or say, most flexible) load order control must include class loading and class initialization e.g.: load: ClassA , load:ClassB, init:ClassB, init:ClassA, load:ClassC > Thierry > > Le 21/11/2013 16:15, Marcus Denker a Ã©crit : > >> >> On 21 Nov 2013, at 15:55, Igor Stasenko <siguctua(a)gmail.com >> <mailto:siguctua@gmail.com>> wrote: >> >> >>> >>> >>> On 21 November 2013 12:30, Marcus Denker <marcus.denker(a)inria.fr >>> <mailto:marcus.denker@inria.fr>> wrote: >>> >>> >>> On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <sven(a)stfx.eu >>> <mailto:sven@stfx.eu>> wrote: >>> >>> > >>> > On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <sven(a)stfx.eu >>> <mailto:sven@stfx.eu>> wrote: >>> > >>> >>> >>> >>> Yes, you can do it per class-hierarchyâ¦ you can implement on >>> the class side a method to parametrize the compiler: >>> >>> >>> >>> compiler >>> >>> ^super compiler options: #(- optionInlineTimesRepeat) >>> >> >>> >> Thanks, Marcus, that works just great. >>> > >>> > Marcus, >>> > >>> > Are we sure this option mechanism works when loading code >>> through Monticello ? >>> > >>> >>> Noâ¦ we should make sure that MC loads the method first. I think it >>> does that for #compilerClass >>> already (but not sure). >>> >>> >>> which is still doesn't eliminates problem completely, because nothing >>> prevents me from having: >>> >>> compilerClass >>> ^ self otherMethod >>> >>> and now in order to work, MC have to know somehow that #otherMethod >>> should also be loaded first. >>> But i think some prioritization guarantees would be really useful. >>> At least i think we can easily prioritize class-side compilation over >>> instance side. >>> Like that, when you compiling any of instance-side method, you know >>> that class side is already there (and can be used >>> as such in different kinds of hooks). >>> >>> >> yes, we need atomic code loading. >> >> Marcus >> > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > -- Best regards, Igor Stasenko.

Nov. 21, 2013

Re: [Pharo-dev] Is Coral still alive?

by Alexandre Bergel

>>> which already exists and it's named LIMBO :) > > Cool! But yes, supporting beyond Mac will be a must. Out of curiosity, why > does it require a plugin? It has seemed to me that one of the purposes of NB > is to bring code into the image, and out of the VM... Good question! I am interested in knowing the answer :-) Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 21, 2013

Re: [Pharo-dev] Tuning Opal Optimizations

by Goubier Thierry

What about having a configuration with a prerequisite package setting up options ? Or optimisation tuning in one of the preload script of the package ? We already have ways to tune that; wouldn't they be better than setting a not so clear class before instance ordering (and what if the class itself requires that kind of tuning?). Thierry Le 21/11/2013 16:15, Marcus Denker a Ã©crit : > > On 21 Nov 2013, at 15:55, Igor Stasenko <siguctua(a)gmail.com > <mailto:siguctua@gmail.com>> wrote: > >> >> >> >> On 21 November 2013 12:30, Marcus Denker <marcus.denker(a)inria.fr >> <mailto:marcus.denker@inria.fr>> wrote: >> >> >> On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <sven(a)stfx.eu >> <mailto:sven@stfx.eu>> wrote: >> >> > >> > On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <sven(a)stfx.eu >> <mailto:sven@stfx.eu>> wrote: >> > >> >>> >> >>> Yes, you can do it per class-hierarchyâ¦ you can implement on >> the class side a method to parametrize the compiler: >> >>> >> >>> compiler >> >>> ^super compiler options: #(- optionInlineTimesRepeat) >> >> >> >> Thanks, Marcus, that works just great. >> > >> > Marcus, >> > >> > Are we sure this option mechanism works when loading code >> through Monticello ? >> > >> >> Noâ¦ we should make sure that MC loads the method first. I think it >> does that for #compilerClass >> already (but not sure). >> >> >> which is still doesn't eliminates problem completely, because nothing >> prevents me from having: >> >> compilerClass >> ^ self otherMethod >> >> and now in order to work, MC have to know somehow that #otherMethod >> should also be loaded first. >> But i think some prioritization guarantees would be really useful. >> At least i think we can easily prioritize class-side compilation over >> instance side. >> Like that, when you compiling any of instance-side method, you know >> that class side is already there (and can be used >> as such in different kinds of hooks). >> > > yes, we need atomic code loading. > > Marcus -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Nov. 21, 2013

Re: [Pharo-dev] NativeBoost: Documentation Suggestion and Question

by Igor Stasenko

On 21 November 2013 16:23, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 13 November 2013 18:08, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > >> Igor Stasenko wrote >> > PaError Pa_OpenDefaultStream(NBExternalAddress * stream ... ) >> > then your call site will look like following: >> > streamHandle := NBExternalAddress new. >> >> Okay, one step closer. I somewhat randomly guessed to use >> NBExternalAddress, >> but didn't have the correct thing in the signature... >> >> >> Igor Stasenko wrote >> > But hold on, next thing you will stuck with is callback ... hehe :) >> > ... >> > for that, again you can just change the function signature and... >> > put nil. (yes, nil literal) >> >> So you're saying the signature would become: >> nbCall: #(PaError Pa_OpenDefaultStream(NBExternalAddress * stream, >> ... >> ulong framesPerBuffer, >> nil, >> void * userData)) >> >> I made the changes as I understood them, but I'm getting a "generic >> failure" >> when I call Pa_OpenDefaultStream. >> >> I uploaded the latest changes to the repo... >> >> >> > sorry for late reply. > > hmm.. everything should work. > except i think nil -> void * is not accepted by default. > you should use #optCoerceNilToNull option: > > self nbCall: ... options: #(+ optCoerceNilToNull) > > or, if you don't wanna mess with options, you can always pass a null > pointer by constructing it, > a simplest way is to pass dumb and stupid > > NBExternalAddress null. > > ... or since i doubt you will ever use userData argument, best option would be to just change the signature and put nil in it, eliminating need to care about passing and converting useless null parameter(s). > >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/NativeBoost-Documentation-Suggestion-and-Question-tp4… >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

Nov. 21, 2013

Re: [Pharo-dev] NativeBoost: Documentation Suggestion and Question

by Igor Stasenko

On 13 November 2013 18:08, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Igor Stasenko wrote > > PaError Pa_OpenDefaultStream(NBExternalAddress * stream ... ) > > then your call site will look like following: > > streamHandle := NBExternalAddress new. > > Okay, one step closer. I somewhat randomly guessed to use > NBExternalAddress, > but didn't have the correct thing in the signature... > > > Igor Stasenko wrote > > But hold on, next thing you will stuck with is callback ... hehe :) > > ... > > for that, again you can just change the function signature and... > > put nil. (yes, nil literal) > > So you're saying the signature would become: > nbCall: #(PaError Pa_OpenDefaultStream(NBExternalAddress * stream, > ... > ulong framesPerBuffer, > nil, > void * userData)) > > I made the changes as I understood them, but I'm getting a "generic > failure" > when I call Pa_OpenDefaultStream. > > I uploaded the latest changes to the repo... > > > sorry for late reply. hmm.. everything should work. except i think nil -> void * is not accepted by default. you should use #optCoerceNilToNull option: self nbCall: ... options: #(+ optCoerceNilToNull) or, if you don't wanna mess with options, you can always pass a null pointer by constructing it, a simplest way is to pass dumb and stupid NBExternalAddress null. > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/NativeBoost-Documentation-Suggestion-and-Question-tp4… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- Best regards, Igor Stasenko.

Nov. 21, 2013

Re: [Pharo-dev] Tuning Opal Optimizations

by Marcus Denker

On 21 Nov 2013, at 15:55, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 21 November 2013 12:30, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >>> > >>> Yes, you can do it per class-hierarchyâ¦ you can implement on the class side a method to parametrize the compiler: > >>> > >>> compiler > >>> ^super compiler options: #(- optionInlineTimesRepeat) > >> > >> Thanks, Marcus, that works just great. > > > > Marcus, > > > > Are we sure this option mechanism works when loading code through Monticello ? > > > > Noâ¦ we should make sure that MC loads the method first. I think it does that for #compilerClass > already (but not sure). > > > which is still doesn't eliminates problem completely, because nothing prevents me from having: > > compilerClass > ^ self otherMethod > > and now in order to work, MC have to know somehow that #otherMethod should also be loaded first. > But i think some prioritization guarantees would be really useful. > At least i think we can easily prioritize class-side compilation over instance side. > Like that, when you compiling any of instance-side method, you know that class side is already there (and can be used > as such in different kinds of hooks). > > yes, we need atomic code loading. Marcus

Nov. 21, 2013

Re: [Pharo-dev] Multithreading

by Camillo Bruni

On 2013-11-21, at 15:56, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > On 20 Nov 2013, at 20:58, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> So what you are looking for is Process and semaphores. >> >> This is not multithreading in the default Pharo VM + image, currently our semaphore/process management is not multithreaded, but executes all the process in the same thread. What happens basically is that you will run several processes in 1 thread with different priorities, and processes with highest priorities will be executed first. This is very good for your case, because if you put your task in another process with lower priority than the UI process, each time you will trigger a UI interaction the secondary process will be temporarily stopped to execute your UI interaction. >> >> (see #forkAt: Process userBackgroundPriority) > > One more thing: how do I synchronise? For example I want two async processes, but when they both finish I want to execute something. Eg. return merged data generated by processes. Semaphores are your friends: semaphore := Semaphore new. [ ... First Job ... semaphore signal. ] fork. [ ... Second Job ... semaphore signal. ] fork. "consume to signals, aka. pause this thread until both jobs have finished" semaphore wait; wait.

Nov. 21, 2013