- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [update 3.0] #30363

by Camillo Bruni

On 2013-09-02, at 12:24, Camillo Bruni <camillobruni(a)gmail.com> wrote: > On 2013-09-02, at 06:07, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> 30363 >> ----- >> >> 11468 Use singleton for default FileSystem >> https://pharo.fogbugz.com/f/cases/11468 > > I'll take care of it later today as usual... more complex than I thought, the change in the FileSystem bootstrap has a negative side-effect on NativeBoost under windows, since everything works if I load it in a running image under windows...

Sept. 3, 2013

Re: [Pharo-dev] Pharo Sprint in Buenos Aires

by Gisela Decuzzi

Great! The idea is to spend the full day? Or do you have any planed time? 2013/9/2 Camillo Bruni <camillobruni(a)gmail.com> > I spend a month in Buenos Aires working together with Guido Chari @ the > UBA, > we take this opportunity to organize a Pharo sprint outside France ;) > > We are in early preparation phase and the date nor location isn't fixed > yet, > so if you are motivated to join, can mark possible dates on this doodle: > > http://doodle.com/qey7iieqm5yr4wwy > > cheers, > camillo >

Sept. 3, 2013

Pharo Sprint in Buenos Aires

by Camillo Bruni

I spend a month in Buenos Aires working together with Guido Chari @ the UBA, we take this opportunity to organize a Pharo sprint outside France ;) We are in early preparation phase and the date nor location isn't fixed yet, so if you are motivated to join, can mark possible dates on this doodle: http://doodle.com/qey7iieqm5yr4wwy cheers, camillo

Sept. 2, 2013

Re: [Pharo-dev] Win32 Console support

by Esteban Lorenzano

is very nice :) but... a bit of criticism (and probably ignorant criticism :P) why those methods names? sets, gets. colored, colorgreen... instead pharoish names? Cheers, Esteban On Sep 2, 2013, at 11:34 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > I played with NativeBoost and the Windows API again > this evening with the result to be able to open a > native Win32 console window, influence title and colors > and write to it from Pharo. This can be useful for coral > and stdout support on Windows too. > > Attached is a screenshot. > > Cleaned up code will follow soon. > > Thx > T. <winconsole.png>

Sept. 2, 2013

Re: [Pharo-dev] Win32 Console support

by Camillo Bruni

nice :) On 2013-09-02, at 18:34, "Torsten Bergmann" <astares(a)gmx.de> wrote: > I played with NativeBoost and the Windows API again > this evening with the result to be able to open a > native Win32 console window, influence title and colors > and write to it from Pharo. This can be useful for coral > and stdout support on Windows too. > > Attached is a screenshot. > > Cleaned up code will follow soon. > > Thx > T. <winconsole.png>

Sept. 2, 2013

Win32 Console support

by Torsten Bergmann

I played with NativeBoost and the Windows API again this evening with the result to be able to open a native Win32 console window, influence title and colors and write to it from Pharo. This can be useful for coral and stdout support on Windows too. Attached is a screenshot. Cleaned up code will follow soon. Thx T.

Sept. 2, 2013

Re: [Pharo-dev] Should Job use SystemAnnouncer?

by Camillo Bruni

On 2013-09-02, at 18:24, Stephan Eggermont <stephan(a)stack.nl> wrote: > Camillo wrote: >> the main problem with the current progress bar morph design is that updates are forced whenever >> the underlying model (here job) changes. This is *very* costly for high-frequency updates, which >> is exactly the moment when you want to use the progress bar ;) >> >> It should work the other way around, the progress bar morph polls the underlying model with a given >> frequency (~10/s) and then refreshes the UI if the model changed. > > I'm not in favor of polling. Most models are not thread-safe. in this case it is only the instance of Job which knows the status. Thread-safeness is not an issue since the progress bar is pure approximation. > The progress bar knows how much precision it has (1% or so) and so knows at which > boundaries it needs to refresh. In addition the progress bar should show that > something is happening a few times a second. that does not work properly and inaccurately reports long running jobs, for instance when running tests. Usually tests take far less than 1 ms, in which case this scheme works perfectly. However from time to time you have 1 test that runs for a couple of seconds. If you run 5000 tests you have to run quite a few tests to get that 1% update margin, so very often the UI does not correctly report the current status. Anyway, this requires quite some changes in the current ProgressBarMorph, so any other improvement until then is welcome :) > For the first, it would be enough to only call self changed in ProgressBarMorph>value: > when the result would be visible, i.e. when the completedWidth changes. > > ProgressBarMorph>value: aNumber > |testWidth| > value := aNumber. > testWidth := self completedWidth. > testWidth ~= cachedWidth ifTrue: [ > cachedWidth := testWidth. > self changed] > > and setting the cachedWidth to 0 on initialize. > > Hmm, where should I commit the 3.0 slice? Getting an error. do you have an account on the Pharo30Inbox repository?

Sept. 2, 2013

Re: [Pharo-dev] Should Job use SystemAnnouncer?

by Stephan Eggermont

Camillo wrote: >the main problem with the current progress bar morph design is that updates are forced whenever >the underlying model (here job) changes. This is *very* costly for high-frequency updates, which >is exactly the moment when you want to use the progress bar ;) > >It should work the other way around, the progress bar morph polls the underlying model with a given >frequency (~10/s) and then refreshes the UI if the model changed. I'm not in favor of polling. Most models are not thread-safe. The progress bar knows how much precision it has (1% or so) and so knows at which boundaries it needs to refresh. In addition the progress bar should show that something is happening a few times a second. For the first, it would be enough to only call self changed in ProgressBarMorph>value: when the result would be visible, i.e. when the completedWidth changes. ProgressBarMorph>value: aNumber |testWidth| value := aNumber. testWidth := self completedWidth. testWidth ~= cachedWidth ifTrue: [ cachedWidth := testWidth. self changed] and setting the cachedWidth to 0 on initialize. Hmm, where should I commit the 3.0 slice? Getting an error. Stephan

Sept. 2, 2013

Re: [Pharo-dev] Smacc question

by StÃ©phane Ducasse

apparently the fileout 30 in VW corrupts the image and I got many strange definitions so I'm checking Stef On Sep 2, 2013, at 12:18 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > Hi thierry > > I imported the generated parsers (a student did a while ago on VW using Smacc). > The generated parser parse apparently the tests. > Now when I regenerate the parser with Pharo I cannot get the Smacc compuling the parser. > I get a SmaCCParserError: Token not expected > > do you have any idea what would not be supported in the Pharo/Squeak version > > > # > # Expression Parser > #============================================= > > goal: expression* ; > > expression: relation > ( ( > and > | > and then > | > or > | > or else > | > xor > ) relation )*; > > relation: simple_expression > sndPart?; > > sndPart: relational_operator simple_expression | > ( > not > )? ( > in range > | > in > type_mark); > > simple_expression: (unary_adding_operator)? > term (binary_adding_operator term)*; > > term: factor (multiplying_operator factor)*; > > factor: primary ( > ** > primary)? | > abs > primary | > not > primary; > > #<identifier> instead of name > primary: <numeric_lit> | > null > | <string_lit> | <number> | > <identifier> | <identifier> > '' > <identifier> | > function_call | > ( > expression > ) > ; > #simplified > > binary_adding_operator: > + > | > - > | > & > ; > unary_adding_operator: > + > | > - > ; > multiplying_operator: > * > | > / > | > mod > | > rem > ; > relational_operator: > = > | > /= > | > < > | > <= > | > > > | > >= > ; > > #============================================================================= > > function_call: <identifier> ''identifier'' function_arguments ''args'' > { ADFunctionCall withElements: args withName: identifier } ; > > function_arguments: > ( > expression ( > , > expression)* > ) > ; > > #==== Declarations =========================================================== > > discrete_range: range | subtype_indication; #discrete_? > > subtype_indication: type_mark (constraint)? ; > > type_mark: type; > > constraint: range_constraint; > > range_constraint: > range > range; > > range: range_attribute | (simple_expression > .. > simple_expression); > > range_attribute: <identifier> > '' > > range > ; #cf. 4.1.4 > > #==== Names ================================================================== > > name: simple_name | <char_lit> | > indexed_component | > slice | selected_component | > attribute; #operator_symbol > > prefix: name | function_call; > > simple_name: <identifier>; > > indexed_component: prefix > ( > expression ( > , > expression )* > ) > ; > > slice: prefix > ( > discrete_range > ) > ; > > selected_component: prefix > . > selector; > > selector: simple_name | <char_lit> | > > all > ; #operator_symbol > > attribute: prefix > '' > attribute_designator; > > attribute_designator: simple_name ( > ( > <universal_static_expression> > ) > )? ; > > #==== Types: appendix c: package STANDARD plus more ========================================================= > type: > BOOLEAN > | > REAL > | > INTEGER > | > FLOAT > | > CHARACTER > | > DURATION > | > > STRING > | > RAINBOW > ; > > '

Sept. 2, 2013

Re: [Pharo-dev] Suggestion about Spec

by Benjamin

I usually try to do so :) Maybe it was 4am, or maybe it collides with Morphic API :) Anyway, it should be more consistent Ben On Sep 2, 2013, at 2:59 PM, Erwan Douaille <douailleerwan(a)gmail.com> wrote: > Hi, > > I'm working on the UIPainter importer. I'm able to import already existing spec windows but now i need to retrieve widgets properties. > > For example, on a ButtonModel i would like to retrieve the Icon. Actually if i want to retrieve it it means than i have to send #iconHolder message. The thing is, to set it we used #icon: > > Why not uniformize it ? For me, #iconHolder should be #icon. It will be more easier for me to retrieve informations, and for users to use it. > > -- > Best regards, > > Douaille Erwan <douaille.erwan(a)gmail.com>

Sept. 2, 2013