- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] about the donwload win.zip pharo 40

by Sergio Fedi

Worked for me too.â

May 20, 2015

Re: [Pharo-dev] Null Coalesce Operator?

by Sergio Fedi

In my experience those situations end up been handled by collections, detect:ifNone: which even handles the case when all defaults are nil. But maybe that idiom is very common in another situations.

May 20, 2015

Null Coalesce Operator?

by Aliaksei Syrel

Hi, Null coalesce operator - returns the first not nil operand. http://en.wikipedia.org/wiki/Null_coalescing_operator Adding one simple method to an Object: ?? anObject > ^ self and to UndefinedObject: ?? anObject > ^ anObject could allow us to write: > default1 := nil. > default2 := nil. > default3 := 'foo'. > default4 := 'don''t care'. > config := default1 ?? default2 ?? default3 ?? default4. => 'foo' I know you don't like to add new methods to an object, but still :)

May 20, 2015

Re: [Pharo-dev] about the donwload win.zip pharo 40

by Nicolai Hess

2015-05-20 20:46 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi > > one student of saint-louis tried to download pharo from the pharo web site > and on windows the archive seems broken. > > Could someone try and let me know? > works for me: http://files.pharo.org/platform/Pharo4.0-win.zip > > Tx. > > Stef > >

May 20, 2015

about the donwload win.zip pharo 40

by stepharo

Hi one student of saint-louis tried to download pharo from the pharo web site and on windows the archive seems broken. Could someone try and let me know? Tx. Stef

May 20, 2015

Re: [Pharo-dev] FileSystem not deleting symlinks

by Damien Pollet

Perhaps a risk of deleting the symlink target instead of the link itself? On 20 May 2015 at 15:46, Damien Cassou <damien.cassou(a)inria.fr> wrote: > The FileSystem library uses DeleteVisitor and PostorderGuide > (depth-first) to delete a directory and all its children. All its > children? No. Symlinks are protected from deletion: > > DeleteVisitor>>visit: aReference > PostorderGuide > show: aReference > to: self > selecting: [ :entry | entry isSymlink not ] > > > I didn't find any unit-test or documentation about why symlinks are > excluded from deletion. I don't see any reason. I'm quite sure the > author had a reason to do that but I don't know which one. > > Anybody has an idea? > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

May 20, 2015

Re: [Pharo-dev] [Pharo 5] For testing: enabled AST based syntax higlighting

by Sean P. DeNigris

Marcus Denker-4 wrote > AST based syntax highlighting This is reeeeaaally cool :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-5-For-testing-enabled-AST-based-syntax-higlight… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 20, 2015

Re: [Pharo-dev] [Pharo-users] MongoTalk: new place on smalltalkhub

by Norbert Hartl

> Am 20.05.2015 um 18:06 schrieb Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > >> >> On 19 May 2015, at 4:52 , Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >> >> Henry, >> >>> Am 19.05.2015 um 13:06 schrieb Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>>: >>> >>> Hi! >>> I made some (imho) improvements to the OID implementation, if someone with write access would find time to review/commit the attached package, I'd be grateful. >>> >>> The commit message: >>> Make OID implementation more compatible with the description in http://docs.mongodb.org/manual/reference/object-id/ <http://docs.mongodb.org/manual/reference/object-id/>. >>> >>> - Use the UNIX epoch instead of Smalltalk epoch for timestamp part, store BE so it's pseudo-sortable by time (also, you can use getTimestamp() in mongo shell and get a sensible value) >> >> Agreed with unix epoch. The old value was in BE also which seems to be the right choice. >> >>> - Use a per-session ID instead of localhost name for machine identification. localhost name is far from unique on some platforms (always 'localhost' on Macs), better with a unique ID per image session. >> >> I do not agree. "NetNameResolver localHostName" does not return localhost for me. And I'd rather think the NetNameResolver does not work properly on Macs (not returning gethostname) instead of taking it as a reason to tweak client code. > > Hmm, yes, it seems localHostName could be implemented better in a way that works on all platforms. > Instead of using the dedicated primitives (primHostNameSize/primHostNameResult:), it tries to lookup the localHostAddress using DNS... > On OSX, primLocalAddress was changed to always return the loopback address so one avoids ambiguities with multiple interfaces, thus, 'localhost'. > I've commit a fixed version to the Pharo 4.0 inbox. > Thanks. But I think pharo 4.0 inbox is more or less closed and you should put it in pharo 5.0 inbox. > I still don't really see the value in using it over a random number that changes when the image goes through a restart cycle, as you can't really do anything useful with it anyways, and the docs do not enforce any specific way of obtaining it. > Yes, you are right. I don't have strong reasons to keep it the old way. It was just my way of asking "if it is not important why did you change it then?" >> The id per Session wouldn't have any value because there is also a process id which gives you more or less the same thing. > > Just to be clear; when I said session, I meant image session, not db-connection session. > My thinking was that, when you can't actually use it to distingush clients anyways, a somewhat-guaranteed-to-be-unique machine id per image > would be a better choice than guaranteed-to-be-identical for all users on Macs. I did understand what you mean. But I don't know when Session is accessed at all. So I assumed that as long as I don't save the image the session will always be created newly on image start. So it is comparable to the process id. That is set on image start and finished on image quit as well. Ok, I've added you to MongoTalkTeam. Just upload the version you find feasible yourself. Norbert > >> >>> - Counter initialized with a random value. >>> >> Good idea. > > A bit more effort to do this if we stick to localHostName, as I piggybacked on the unused random bits in the UUID used to replace machineIdentifier for that, the other ways of getting random numbers in a cross-platform manner is rather hit-and-miss, both wrt quality and performance. >> >>> As an added bonus, [OID new] bench should see a ~10% increase in performance. >>> >> Even better. :) >> >> What do you think? >> >> I can make you a commiter on the MongoTalk repo. What's your username? > > henriksp is my user name. > > I tinkered some more, at the cost of readability, additional optimizations (by removing temporary object creations), can result in an order of magnitude more executions during a simple #bench test. > Whether one actually needs to create 200k UIDs/second instead of 20k is another question, but in my experience, DB-interfaces can never be *too* low overhead... > > Cheers, > Henry

May 20, 2015

Re: [Pharo-dev] [Pharo-users] MongoTalk: new place on smalltalkhub

by Henrik Johansen

> On 19 May 2015, at 4:52 , Norbert Hartl <norbert(a)hartl.name> wrote: > > Henry, > >> Am 19.05.2015 um 13:06 schrieb Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>>: >> >> Hi! >> I made some (imho) improvements to the OID implementation, if someone with write access would find time to review/commit the attached package, I'd be grateful. >> >> The commit message: >> Make OID implementation more compatible with the description in http://docs.mongodb.org/manual/reference/object-id/ <http://docs.mongodb.org/manual/reference/object-id/>. >> >> - Use the UNIX epoch instead of Smalltalk epoch for timestamp part, store BE so it's pseudo-sortable by time (also, you can use getTimestamp() in mongo shell and get a sensible value) > > Agreed with unix epoch. The old value was in BE also which seems to be the right choice. > >> - Use a per-session ID instead of localhost name for machine identification. localhost name is far from unique on some platforms (always 'localhost' on Macs), better with a unique ID per image session. > > I do not agree. "NetNameResolver localHostName" does not return localhost for me. And I'd rather think the NetNameResolver does not work properly on Macs (not returning gethostname) instead of taking it as a reason to tweak client code. Hmm, yes, it seems localHostName could be implemented better in a way that works on all platforms. Instead of using the dedicated primitives (primHostNameSize/primHostNameResult:), it tries to lookup the localHostAddress using DNS... On OSX, primLocalAddress was changed to always return the loopback address so one avoids ambiguities with multiple interfaces, thus, 'localhost'. I've commit a fixed version to the Pharo 4.0 inbox. I still don't really see the value in using it over a random number that changes when the image goes through a restart cycle, as you can't really do anything useful with it anyways, and the docs do not enforce any specific way of obtaining it. > The id per Session wouldn't have any value because there is also a process id which gives you more or less the same thing. Just to be clear; when I said session, I meant image session, not db-connection session. My thinking was that, when you can't actually use it to distingush clients anyways, a somewhat-guaranteed-to-be-unique machine id per image would be a better choice than guaranteed-to-be-identical for all users on Macs. > >> - Counter initialized with a random value. >> > Good idea. A bit more effort to do this if we stick to localHostName, as I piggybacked on the unused random bits in the UUID used to replace machineIdentifier for that, the other ways of getting random numbers in a cross-platform manner is rather hit-and-miss, both wrt quality and performance. > >> As an added bonus, [OID new] bench should see a ~10% increase in performance. >> > Even better. :) > > What do you think? > > I can make you a commiter on the MongoTalk repo. What's your username? henriksp is my user name. I tinkered some more, at the cost of readability, additional optimizations (by removing temporary object creations), can result in an order of magnitude more executions during a simple #bench test. Whether one actually needs to create 200k UIDs/second instead of 20k is another question, but in my experience, DB-interfaces can never be *too* low overhead... Cheers, Henry

May 20, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50055 Home: https://github.com/pharo-project/pharo-core

May 20, 2015