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

Re: [Pharo-dev] ConfigurationOfMongoTalk load?

by Sebastian Sastre

sorry yeah itâs a fresh image, latest version: 30814 I can only load it using bleedingEdge On Apr 4, 2014, at 4:50 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Loads fine in a fresh 3.0 image for me. How did you load it? You should give some version numbers along with the problem! > > Norbert > > Am 04.04.2014 um 21:30 schrieb Sebastian Sastre <sebastian(a)flowingconcept.com>: > >> #load complains about no defined stable* >> >> should I load bleeding edge or development? >> >> BTW they sound like the same thing, whatâs the difference between those branches? >> >> >> >> *suggestion: even if itâs beta or alpha I would make a stable just to set a foundation that does not confuses the users >> >> > >

April 4, 2014

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

by Igor Stasenko

On 4 April 2014 22:54, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 04 Apr 2014, at 19:29, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > 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. > > All this is quite interesting (and makes my head hurt), maybe we should > implement this as a helper class in the image, along side the other lock > free stuff ? > > i don't know.. do you think it shall be part of some 'atomics' library? >From other side, for same problem there can be many different solutions.. For instance, if you need to uniquely identify an object, what can be simpler than just using that object (identity)? And simplest way to obtain unique object, which nobody can read/write to, is to allocate a new one.. and as long as you don't give a reference to it, it is free from any concurrency caveats.. -- Best regards, Igor Stasenko.

April 4, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] 807595: 30813

by Sven Van Caekenberghe

On 04 Apr 2014, at 16:37, GitHub <noreply(a)github.com> wrote: > 13114 Broken PharoTheme > https://pharo.fogbugz.com/f/cases/13114 > > 12966 FileLocator does not support adding extension with , > https://pharo.fogbugz.com/f/cases/12966 > > 13151 Fix side bar buttons > https://pharo.fogbugz.com/f/cases/13151 Ah, Pharo looks normal again, sanity restored ;-) Thx !

April 4, 2014

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

by Sven Van Caekenberghe

On 04 Apr 2014, at 19:29, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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. All this is quite interesting (and makes my head hurt), maybe we should implement this as a helper class in the image, along side the other lock free stuff ? > 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] ConfigurationOfMongoTalk load?

by Norbert Hartl

Loads fine in a fresh 3.0 image for me. How did you load it? You should give some version numbers along with the problem! Norbert Am 04.04.2014 um 21:30 schrieb Sebastian Sastre <sebastian(a)flowingconcept.com>: > #load complains about no defined stable* > > should I load bleeding edge or development? > > BTW they sound like the same thing, whatâs the difference between those branches? > > > > *suggestion: even if itâs beta or alpha I would make a stable just to set a foundation that does not confuses the users > >

April 4, 2014

ConfigurationOfMongoTalk load?

by Sebastian Sastre

#load complains about no defined stable* should I load bleeding edge or development? BTW they sound like the same thing, whatâs the difference between those branches? *suggestion: even if itâs beta or alpha I would make a stable just to set a foundation that does not confuses the users

April 4, 2014

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

by Pharo4Stef

On 04 Apr 2014, at 19:26, J.F. Rick <self(a)je77.com> wrote: > 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. yes this would be nice. And a fix for that. Did you also see that what I like is to make a distinction between a possible selector and a wrong one? because this is nice. > > 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 Pharo4Stef

This is strange because the system is looking for the correct location but does not find them. On 04 Apr 2014, at 19:09, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > 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] font folder on win7

by Pharo4Stef

thanks! On 04 Apr 2014, at 19:44, Vincent BLONDEAU <vincent.blondeau(a)polytech-lille.net> wrote: > 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] Suggested Syntax Highlighting Features for Beginners

by kilon alios

I fail to see confusion as a bad thing though. For me confusion is part of the learning process. Being successful at something is about developing the skills for it and that takes time and practice. I am no beginner or pro coder but frankly I am glad that assignment is := and comparison is =. Cant stress enough how many times I made the stupid mistake in python (the language I have most coding experience with) doing a if a=1 instead of if a==1 and its a bug that is painful to spot . Maybe I am smalltalker by birth :D but for my brain comparison is =. And though I had many arguments with my brain about it, he does not seem to want to change its mind about it. Frankly I dont think seeing that = in different color would make much of difference at least for my mistakes. But definitely would not hurt either. About command completion cant stress enough how crucial is for people like me with very bad memory. I keep forgetting names of people that have met recently, method names and class names have no chance of being remembered , when I have to deal with hundreds and thousands of them. I would love if my brain had some kind of autocompletion but it looks like my brain still runs on Windoom. Again with messages sends and multiple arguments , I love the mandatory keyword argument about Smalltalk again for someone like myself with real bad memory is just a ton of help. I just dont want to go back to unnamed arguments. Again code completion helps here. Anyway I know this is a single opinion but I am still a beginner smalltalker though not a beginner coder. Because there is like a ton of people that out there try to identify what went so bad with Smalltalk and never become truly popular , my opinion is that it has nothing to do with the language. The language is brilliantly simple and straight forward, I wish I could say the same about the libraries. Its the libraries I struggle the most when I play with pharo. At time I am afraid to look at the next method because I feel it will be the portal to spaghetti hell. I cant think a bigger nightmare for a newcomer especially when there is lack of documentation. For me thats the true dark side of Pharo. But again just an opinion. On Fri, Apr 4, 2014 at 8:26 PM, J.F. Rick <self(a)je77.com> wrote: > 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