April 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] font folder on win7

by Vincent BLONDEAU

The best is to use environment variables : Under W7 it is : %SYSTEMROOT%\Fonts But you can get it under Pharo: PlatformResolver forCurrentPlatform directoryFromEnvVariableNamed: 'SYSTEMROOT' Vincent De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de Chris Cunningham EnvoyÃ© : vendredi 4 avril 2014 19:09 Ã : Pharo Development List Objet : Re: [Pharo-dev] font folder on win7 It is located in \Windows\Fonts (and window is case-agnostic, so \windows\fonts works as well) -cbc On Fri, Apr 4, 2014 at 9:48 AM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: Hi guys IÂm trying to understand why people get problems with fonts on windows. The logic in the font manager is 'cdefghijklmnopqrstuvwxyz' et pour chaque disc dans '\windows\fonts' '\winnt\fonts but I wonder if the location of font on windows 7 is correct. Can anybody with a window 7 report where the fonts are located? stef

April 4, 2014

Re: [Pharo-dev] Lock-free Atomic Counter ?

by Igor Stasenko

On 4 April 2014 18:31, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Just for the sake of discussion, you try to prevent interruptions by using > assignments, right ? But you still need #== which seems like a (potential) > message send, which brings us back to the other arguments in this thread. > Furthermore, the dummy value must be different for each of the > processes/threads entering, no ? > > dummy is placeholder used solely to detect that counter is 'locked' via #== comparison.. can be any object not really matters if you share it among processes or not, since it carries no state. #== , whileTrue: .. as well as any other message sends potentially is subject of being interrupted.. but there's nothing wrong with it, as long as two assignments (in a row) don't have chance to be interrupted. > On 03 Apr 2014, at 01:34, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > so, lock-free counter can be something like: > > > > atomicIncr > > | oldValue | > > > > [ > > oldValue := self atomicSwapCounterWithDummy. > > oldValue == dummy ] whileTrue: [ Processor yield ]. > > > > ^ counter := oldValue + 1 > > > > > > atomicSwapCounterWithDummy > > | old | > > old := counter. > > counter := dummy. > > ^ old > > > > so you use dummy to block anyone from setting the new value unless you > set it. > > dummy can be any object (not a number in your care), > > and lastly, once you assign a new value, you effectively release a "lock" > > :) > > > > Processor yield is mainly attempt to avoid busy-waiting. > > > > > > > > On 3 April 2014 01:28, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > > > > > On 3 April 2014 00:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > > > Is it possible to have a simple lock-free atomic counter in Pharo 3.0 ? > > > > nextId > > ^ idCounter := idCounter + 1 > > > > Or is it still possible that two process entering this code can mess > things up ? > > > > #+ is a message send. So technically, if you will be interrupted at the > point of > > returning a result from it, then somebody else could run #nextId without > notice, > > as result you will get 2 processes returning same value from #nextId. > > (and increasing numbers of concurrent processes will produce even more > surprising results :) > > > > I vaguely remember a discussion about that long ago... > > > > assignment is atomic.. the one which i use in atomic queue impl., but it > is hidden, undocumented VM implementation detail :) e.g.: > > > > oldA := a. > > a := newA. > > .. > > actually can be any series of it, as long as nothing else there (no > message sends) > > > > x:= a. > > y:=b. > > z := c. > > w := e. > > > > will be performed atomically. > > > > > > TIA, > > > > Sven > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > -- Best regards, Igor Stasenko.

April 4, 2014

Re: [Pharo-dev] Suggested Syntax Highlighting Features for Beginners

by J.F. Rick

On Fri, Apr 4, 2014 at 6:41 PM, Ben Coman <btc(a)openinworld.com> wrote: > For assignment, I would say bold both := and the variable being assigned > to. > I like that a lot, especially since it draws the two critical elements of variable and assignment together. On a minor note, both := and = are currently the same color: black. That only furthers the ":= is a message" misconception. It might be worthwhile also giving := its own color, given its uniqueness. > Underlining sounds interesting, but there are a few choices: > a. nested underlining - self someMessage: (self otherMessage: arg 1 and: > arg2) and: arg3 > b. non-nested underlining - only underline #otherMessage:and: and not > #someMessage:and: > c. dynamically underline only message where cursor is located. > I think you could do nested underlining in the same way that nested blocks and parentheses work. someMessage: and the second and: are underlined in black. otherMessage: and the first and: are underlined in green. That way nesting is clear. This would also be useful for code with nested conditionals, probably the most common occurrence of nested multi-part messages. I also like (c) as a minimally intrusive change that could help novices when they write code. It has the disadvantage that novices couldn't look at a piece of foreign code and get where the multi-part messages were. Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

April 4, 2014

Re: [Pharo-dev] font folder on win7

by Chris Cunningham

It is located in \Windows\Fonts (and window is case-agnostic, so \windows\fonts works as well) -cbc On Fri, Apr 4, 2014 at 9:48 AM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > Hi guys > > > I'm trying to understand why people get problems with fonts on windows. > The logic in the font manager is > > 'cdefghijklmnopqrstuvwxyz' > et pour chaque disc dans '\windows\fonts' '\winnt\fonts > > > but I wonder if the location of font on windows 7 is correct. > Can anybody with a window 7 report where the fonts are located? > > stef >

April 4, 2014

Re: [Pharo-dev] left over when resizing window

by Esteban Lorenzano

On 03 Apr 2014, at 17:44, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 3 April 2014 16:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > that happens in retina displays. > Iâm awareâ¦ no time yet to fix it :( > > Esteban, still on holidays > > btw, again and again i forgetting ask you to show me what i should change to disable "half resolution" mode > while on retina displays.. > i wanna use full resolution, for aestetical testing of font rendering without subpixel(s).. > by athens/cairo :) basically, we have to change the scale of the NSView who contains the world. probably trivialâ¦ but one of those small things I never found the time to fix (always something more urgent). Esteban (yepâ¦ still on holidays :P) > > > > On 03 Apr 2014, at 11:32, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > > This is this kind of glitches (see screenshot) ? > > I already talk about that some months ago in the mailing-list. > > > > On Thu, Apr 3, 2014 at 3:11 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Funny that you do not see the same issues. > >> > >> I reproduce it consistently like this: > >> - On 10.9.2 on a MacBook Pro with Retina display > >> - Download the latest Pharo 3 and the latest VM and run it: > >> curl -L get.pharo.org/30+vmLatest | sh > >> - Open a workspace or any other window and drag it around > >> > >> > >> Doru > >> > >> > >> Doru > >> > >> > >> On Thu, Apr 3, 2014 at 3:04 PM, Camille Teruel <camille.teruel(a)gmail.com> > >> wrote: > >>> > >>> > >>> On 3 avr. 2014, at 14:58, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >>> > >>> Hi, > >>> > >>> Here it is on the very latest of Pharo 3: > >>> > >>> https://www.dropbox.com/s/hfi5j64e9kyim14/Screenshot%202014-04-03%2014.56.3… > >>> > >>> > >>> Ok, now I remember that I had that once several months ago, but I don't > >>> remember under which setting. > >>> I solved it with 'start drawing/stepping again' as Sergi said. > >>> We should find a way to reproduce it. > >>> > >>> > >>> Pharo3.0 Latest update: #30811 > >>> 'NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: > >>> acc98e51-2fba-4841-a965-2975997bba66 Mar 20 2014 > >>> NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: > >>> acc98e51-2fba-4841-a965-2975997bba66 Mar 20 2014 > >>> https://github.com/pharo-project/pharo-vm.git Commit: > >>> 6e08ad296c0df6c1a4215a5dada5380c897dc2fe Date: 2014-03-17 14:45:12 +0100 By: > >>> Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14812' > >>> > >>> > >>> Cheers, > >>> Doru > >>> > >>> > >>> > >>> > >>> On Thu, Apr 3, 2014 at 2:33 PM, Camille Teruel <camille.teruel(a)gmail.com> > >>> wrote: > >>>> > >>>> > >>>> On 3 avr. 2014, at 14:21, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >>>> > >>>> It happens all the time on Mac. It is not so obvious in the default Pharo > >>>> image because of the background. In the Moose image, the background is white > >>>> and you see it immediately when resizing or dragging a window. > >>>> > >>>> > >>>> I tried with many windows in the latest Moose image and I still see > >>>> nothing. > >>>> I'm on mavericks. > >>>> > >>>> Smalltalk vm version --> > >>>> > >>>> 'NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: > >>>> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > >>>> NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: > >>>> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > >>>> git://gitorious.org/cogvm/blessed.git Commit: > >>>> 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: > >>>> Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 > >>>> ' > >>>> > >>>> > >>>> Doru > >>>> > >>>> > >>>> On Thu, Apr 3, 2014 at 2:16 PM, Camille Teruel <camille.teruel(a)gmail.com> > >>>> wrote: > >>>>> > >>>>> > >>>>> On 3 avr. 2014, at 13:54, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > >>>>> > >>>>>> Hi all > >>>>>> > >>>>>> do you see a glitch when I resize a window? > >>>>>> Because it is not really nice. > >>>>> > >>>>> Nope, nothing in latest image at least. > >>>>> Does it happen in a fresh image? > >>>>> > >>>>>> Stef > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> www.tudorgirba.com > >>>> > >>>> "Every thing has its own flow" > >>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> www.tudorgirba.com > >>> > >>> "Every thing has its own flow" > >>> > >>> > >> > >> > >> > >> -- > >> www.tudorgirba.com > >> > >> "Every thing has its own flow" > > > > > > > > -- > > Serge Stinckwich > > UCBN & UMI UMMISCO 209 (IRD/UPMC) > > Every DSL ends up being Smalltalk > > http://www.doesnotunderstand.org/ > > <Screen Shot 2014-04-03 at 16.30.05.png> > > > > > > -- > Best regards, > Igor Stasenko.

April 4, 2014

font folder on win7

by Pharo4Stef

Hi guys Iâm trying to understand why people get problems with fonts on windows. The logic in the font manager is 'cdefghijklmnopqrstuvwxyz' et pour chaque disc dans '\windows\fonts' '\winnt\fonts but I wonder if the location of font on windows 7 is correct. Can anybody with a window 7 report where the fonts are located? stef

April 4, 2014

Re: [Pharo-dev] Suggested Syntax Highlighting Features for Beginners

by Ben Coman

J.F. Rick wrote: > Smalltalk is a pretty great language, but its syntax is unusual. I've > taught introductory programming in Pharo three times and, in my > experience, there are two places where novices get repeatedly confused > with syntax. > > First, there is the differences between assignment := and comparison = > . Obviously, Smalltalk is not the only language where that is a > problem. Java is even more confusing, with assignment = and comparison > == . In Squeak, there was the attempt to address this problem head on > with using _ instead of := and having it show up as an arrow pointing > left; while that nicely addressed that problem, it proved awkward for > many reasons (e.g., it only appeared as an arrow in Squeak, it wasn't > compatible with other Smalltalks). In addition, comparison is a simple > message send, where assignment is the most critical language element > that is not an object or a message. In other words, there is a huge > difference in meaning between the two and a really minor syntactical > one. That's confusing to novices. Even after covering it repeatedly in > class I still find novices making that mistake. As their debugging > skills are minimal, this can be a real obstacle. > > Second, there is the problem of keyword messages with more than one > argument. In Java, "this.someMessage( arg1, arg2)" is pretty > comprehensible to a novice. In Smalltalk, "self someMessage: arg1 and: > arg2" seems like two message sends (i.e., > "this.someMessage(arg1).and(arg2)"). While novices won't see > multi-argument messages very often, they do come up (e.g., > ifTrue:ifFalse:). I have my class do regular quizzes on identifying > messages and this still tricks them up even if they've already seen in > 10 times. > > Now, I'm not advocating changing the Smalltalk syntax; that's just > unlikely to happen. But, perhaps syntax highlighting could be employed > to good use. For instance, it is extremely helpful that blocks and > parentheses show by color which ( [ go with which ] ). Perhaps > something similar could be done for messages with more than 1 > argument. For instance, the message could be underlined in different > colors. That way I could easily see which ifFalse: went with which > ifTrue:. It would also give a visual indicator: (for novices) Be > careful, this message is one of those weird ones that's longer than it > first appears. For assignment vs comparison, you similarly need a > powerful visual cue that assignment is an usual thing, where > comparison is a pretty ordinary thing. Perhaps an arrow decoration > could appear behind the :=. > > These may seem like trivial issues. For experts, they are. I don't > need any of it. I don't find syntax highlighting and command > completion that useful in my programming. But, I'm proficient with a > debugger. Should I occasionally make such a trivial mistake (e.g., > forgetting to type : in :=), I immediately find it while debugging and > easily fix it. For novices, using a debugger is not an option. > Remember, they don't understand what a stack is. Syntax highlighting > is the best debugging feature that they understand. And these are two > real common mistakes that they make that could be addressed by > improvements to syntax highlighting. > > Just a suggestion, > > Jeff > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick For assignment, I would say bold both := and the variable being assigned to. Underlining sounds interesting, but there are a few choices: a. nested underlining - self someMessage: (self otherMessage: arg 1 and: arg2) and: arg3 b. non-nested underlining - only underline #otherMessage:and: and not #someMessage:and: c. dynamically underline only message where cursor is located. I prefer (c.). This would be least annoying to the experts, and maybe not even need a Preference. Students don't have it as a continual crutch - but they can easily check whenever needed with a tight feedback loop most productive for learning. cheers, Ben

April 4, 2014

Re: [Pharo-dev] Lock-free Atomic Counter ?

by Sven Van Caekenberghe

Just for the sake of discussion, you try to prevent interruptions by using assignments, right ? But you still need #== which seems like a (potential) message send, which brings us back to the other arguments in this thread. Furthermore, the dummy value must be different for each of the processes/threads entering, no ? On 03 Apr 2014, at 01:34, Igor Stasenko <siguctua(a)gmail.com> wrote: > so, lock-free counter can be something like: > > atomicIncr > | oldValue | > > [ > oldValue := self atomicSwapCounterWithDummy. > oldValue == dummy ] whileTrue: [ Processor yield ]. > > ^ counter := oldValue + 1 > > > atomicSwapCounterWithDummy > | old | > old := counter. > counter := dummy. > ^ old > > so you use dummy to block anyone from setting the new value unless you set it. > dummy can be any object (not a number in your care), > and lastly, once you assign a new value, you effectively release a "lock" > :) > > Processor yield is mainly attempt to avoid busy-waiting. > > > > On 3 April 2014 01:28, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 3 April 2014 00:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > Is it possible to have a simple lock-free atomic counter in Pharo 3.0 ? > > nextId > ^ idCounter := idCounter + 1 > > Or is it still possible that two process entering this code can mess things up ? > > #+ is a message send. So technically, if you will be interrupted at the point of > returning a result from it, then somebody else could run #nextId without notice, > as result you will get 2 processes returning same value from #nextId. > (and increasing numbers of concurrent processes will produce even more surprising results :) > > I vaguely remember a discussion about that long ago... > > assignment is atomic.. the one which i use in atomic queue impl., but it is hidden, undocumented VM implementation detail :) e.g.: > > oldA := a. > a := newA. > .. > actually can be any series of it, as long as nothing else there (no message sends) > > x:= a. > y:=b. > z := c. > w := e. > > will be performed atomically. > > > TIA, > > Sven > > > > -- > Best regards, > Igor Stasenko. > > > > -- > Best regards, > Igor Stasenko.

April 4, 2014

Re: [Pharo-dev] Lock-free Atomic Counter ?

by Sven Van Caekenberghe

Thanks guys for all the answers, I think I am going to stick with the simple code and no protection based on the arguments that I read. It will do for my application where nothing catastrophic will happen when in case of a clash. On 03 Apr 2014, at 00:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > Is it possible to have a simple lock-free atomic counter in Pharo 3.0 ? > > nextId > ^ idCounter := idCounter + 1 > > Or is it still possible that two process entering this code can mess things up ? > > I vaguely remember a discussion about that long ago... > > TIA, > > Sven

April 4, 2014

Re: [Pharo-dev] [pharo3 issues] down to 17 issues

by MartinW

When i add a new bug to the issue tracker it is automatically tagged as "fix if time". Am i supposed to change this label to higher priority if i think it's appropriate - or is someone reviewing new entered bugs and assigning priorities to them? Anyway here's the bug: https://pharo.fogbugz.com/f/cases/13175/ -- View this message in context: http://forum.world.st/pharo3-issues-down-to-17-issues-tp4752772p4752800.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 4, 2014