November 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] #at:ifAbsent: for Array(s) could be faster

by blake

Am I crazy to think that this reflect a language-expressiveness issue? I mean, I can think of a couple of ways around it, like implement #at: code in the #at:ifAbsent routine (which violates DRY), or have an #__unsafe_at:. And it seems like there'd be lots of cases of this, though I could be wrong. And maybe there aren't enough cases of this to matter, but it seems like it should be possible to group methods under a particular set of validations/safety checks. They could require them without performing them. Theoretically, anyway. Heh. On Wed, Nov 2, 2011 at 12:55 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Wed, Nov 2, 2011 at 11:33 AM, Levente Uzonyi <leves(a)elte.hu> wrote: > >> On Wed, 2 Nov 2011, Igor Stasenko wrote: >> >> Here the original implementation, which Array inherits from >>> SequenceableCollection: >>> >>> at: index ifAbsent: exceptionBlock >>> "Answer the element at my position index. If I do not contain an >>> element >>> at index, answer the result of evaluating the argument, >>> exceptionBlock." >>> >>> (index between: 1 and: self size) ifTrue: [^ self at: index]. >>> ^ exceptionBlock value >>> >>> >>> the thing is, that #at: primivite also doing a range checking and >>> fails if index is invalid, so if index is valid, as result we >>> performing a range checking twice instead of just once. >>> >>> Here the simple implementation how to make things faster: >>> fat: index >>> "Primitive. Assumes receiver is indexable. Answer the value of an >>> indexable element in the receiver. Fail if the argument index is >>> not an >>> Integer or is out of bounds. Essential. See Object documentation >>> whatIsAPrimitive. Read the class comment for a discussion about >>> that the fact >>> that the index can be a float." >>> >>> <primitive: 60> >>> ^ #plopp >>> >>> fat: index ifAbsent: aBlock >>> | x | >>> x := (self fat: index). >>> x == #plopp ifTrue: [ ^ aBlock value ]. >>> ^ x >>> >>> And speedup is almost 2 times: >>> >>> [ 1000000 timesRepeat: [ #(1 2 4 5 56 67 67) at: 1 ifAbsent: nil ] ] >>> timeToRun >>> >>> 39 >>> >>> [ 1000000 timesRepeat: [ #(1 2 4 5 56 67 67) at: 1 ifAbsent: nil ] ] >>> timeToRun >>> >>> 20 >>> >>> Even when index is out of range, it is still much faster: >>> >>> [ 1000000 timesRepeat: [ #(1 2 4 5 56 67 67) at: 100 ifAbsent: nil ] ] >>> timeToRun >>> >>> 35 >>> >>> [ 1000000 timesRepeat: [ #(1 2 4 5 56 67 67) fat: 100 ifAbsent: nil ] >>> ] timeToRun >>> >>> 24 >>> >>> The problem, of course, that trick with #plopp is a dirty hack. >>> Because if array include an #plopp object as element, it will report >>> as it absent, >>> instead of answering it. >>> There is no way to ensure that any arbitrary object are never included >>> as element in array, so this is no-go for generic replacement. >>> But in controlled environment, when you know that none of arrays which >>> you using with #fat:ifAbsent: will ever include #plopp (or pick your >>> own unique object) >>> it may be a good alternative. >>> >> >> I've been thinking about this earlier and there's a much nicer and >> simpler solution, though it requires vm changes :). The idea is to change >> primitive 60 to work for 2 parameters too, so #at:ifAbsent: could also use >> the primitive directly. There were a few changes about #at: recently >> (mirror prims, cog), so I'm not sure it's still easy to change the >> primitive. >> > > his is neat, but it wouldn't be an extension to primitive 60 but a new > primitive that would ignore its top of stack. primitive 60 can operate > with 2 args,when used as a mirror primitive, but then it ignores the > receiver. Your usage would ignore the last argument. > > So choose a primitive number and I'll make it so... > > >> >> Levente >> >> >> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >>> >>> >> > > > -- > best, > Eliot > >

Nov. 3, 2011

[Pharo-project] Moving a file

by Sean P. DeNigris

Neither the Squeak file system support, nor FS seem to contain logic to move a file, like Unix's mv command. This seems like a basic piece of functionality. Why is it missing? Thanks. Sean -- View this message in context: http://forum.world.st/Moving-a-file-tp3983916p3983916.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 3, 2011

Re: [Pharo-project] Storing all source code in a relational database

by Stephan Eggermont

... is a waste of time and computing resources. Relational databases are optimized for specific usage scenarios. CAD systems and source code management systems are the archetypical examples of systems that are a bad fit and will kill the performance of a relational database. Of course 30 years later you can brute force it, but that doesn't make it a good idea. Git is far superior to rdb based systems for the day-to-day work and the analytics should be done from a ram-based object model. Stephan

Nov. 2, 2011

Re: [Pharo-project] Brainstorming on the roadmap for first Pharo Consortium Engineer :)

by Luc Fabresse

2011/11/2 Eliot Miranda <eliot.miranda(a)gmail.com> > > > On Mon, Oct 31, 2011 at 1:56 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> - Once again... I would LOVE to have a really working-out-of-the-box >> multithreaded FFI with callbacks. >> > > and for me to finish my part of this (the VM implementation and Alien > support) I need review of my VM code. Since Cadence want this too I should > be in a position to spend considerable time on it in a few weeks. > really great news! Luc > > >> This is a MUST if Pharo wants to be business friendly. >> > > I couldn't agree more. A platform must have an excellent FFI to be useful. > > >> >> - Unify the VMs. Have only ONE place where a single pharo user can go and >> pickup a VM. Have ANOTHER place for those bleeding edge or experiment VMs. >> This means merging gforge, jenkins, pharo website, pharo one click, etc. >> In addition, we need a way to IDENTIFY a VM. So that when someone reports >> a bug, we can exactly know which VM to reproduce it. >> >> - Integrate Nautilus with RB. Nobody (ok, most of us) cannot work without >> RB integration. Ok, integrations could live without that, but they >> INTEGRATE. If you are DEVELOPING you cannot develop without RB. If nobody >> will make OB to work in 1.4, then someone needs to integrate Nautilus with >> RB, otherwise people will stick with 1.3 and never change. >> >> - Make development really tools work in Pharo 1.4: OCompletion, Shout >> >> - Continue pushing Coral, Zinc, Ocean, DBXTalk, Fuel, Nautilus, etc. >> >> - Maintain issue tracker: let's give Marcus a rest. This means tagging >> issues, close them, validate, etc etc etc. >> >> Cheers >> >> >> On Mon, Oct 31, 2011 at 8:25 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: >> >>> I can't take credit for thinking of the bridge, I was simply >>> acknowledging it and the breadth of its audience as part of my shameless >>> attempt to direct effort toward another feature that would get a lot of use >>> :) >>> >>> Bill >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [ >>> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sean P. >>> DeNigris [sean(a)clipperadams.com] >>> Sent: Monday, October 31, 2011 3:22 PM >>> To: pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Brainstorming on the roadmap for first >>> Pharo Consortium Engineer :) >>> >>> Schwab,Wilhelm K wrote: >>> > >>> > The object-c bridge is probably a big deal to the Mac users among us, >>> > right? >>> >>> Yes! Thank you for the reminder, I'd temporarily given up and forgotten >>> about this. A stable, well-documented ObjC bridge would be /huge/. My >>> inability to effectively use it was one of the key drivers in my delving >>> into debugging the VM. Like FFI, I think documentation will be extremely >>> important here. >>> >>> Sean >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Brainstorming-on-the-roadmap-for-first-Pharo-Consorti… >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > -- > best, > Eliot > >

Nov. 2, 2011

Re: [Pharo-project] Brainstorming on the roadmap for first Pharo Consortium Engineer :)

by Eliot Miranda

On Mon, Oct 31, 2011 at 1:56 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > - Once again... I would LOVE to have a really working-out-of-the-box > multithreaded FFI with callbacks. > and for me to finish my part of this (the VM implementation and Alien support) I need review of my VM code. Since Cadence want this too I should be in a position to spend considerable time on it in a few weeks. > This is a MUST if Pharo wants to be business friendly. > I couldn't agree more. A platform must have an excellent FFI to be useful. > > - Unify the VMs. Have only ONE place where a single pharo user can go and > pickup a VM. Have ANOTHER place for those bleeding edge or experiment VMs. > This means merging gforge, jenkins, pharo website, pharo one click, etc. > In addition, we need a way to IDENTIFY a VM. So that when someone reports > a bug, we can exactly know which VM to reproduce it. > > - Integrate Nautilus with RB. Nobody (ok, most of us) cannot work without > RB integration. Ok, integrations could live without that, but they > INTEGRATE. If you are DEVELOPING you cannot develop without RB. If nobody > will make OB to work in 1.4, then someone needs to integrate Nautilus with > RB, otherwise people will stick with 1.3 and never change. > > - Make development really tools work in Pharo 1.4: OCompletion, Shout > > - Continue pushing Coral, Zinc, Ocean, DBXTalk, Fuel, Nautilus, etc. > > - Maintain issue tracker: let's give Marcus a rest. This means tagging > issues, close them, validate, etc etc etc. > > Cheers > > > On Mon, Oct 31, 2011 at 8:25 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > >> I can't take credit for thinking of the bridge, I was simply >> acknowledging it and the breadth of its audience as part of my shameless >> attempt to direct effort toward another feature that would get a lot of use >> :) >> >> Bill >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sean P. >> DeNigris [sean(a)clipperadams.com] >> Sent: Monday, October 31, 2011 3:22 PM >> To: pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Brainstorming on the roadmap for first Pharo >> Consortium Engineer :) >> >> Schwab,Wilhelm K wrote: >> > >> > The object-c bridge is probably a big deal to the Mac users among us, >> > right? >> >> Yes! Thank you for the reminder, I'd temporarily given up and forgotten >> about this. A stable, well-documented ObjC bridge would be /huge/. My >> inability to effectively use it was one of the key drivers in my delving >> into debugging the VM. Like FFI, I think documentation will be extremely >> important here. >> >> Sean >> >> -- >> View this message in context: >> http://forum.world.st/Brainstorming-on-the-roadmap-for-first-Pharo-Consorti… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- best, Eliot

Nov. 2, 2011

Re: [Pharo-project] #at:ifAbsent: for Array(s) could be faster

by Eliot Miranda

On Wed, Nov 2, 2011 at 11:33 AM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Wed, 2 Nov 2011, Igor Stasenko wrote: > > Here the original implementation, which Array inherits from >> SequenceableCollection: >> >> at: index ifAbsent: exceptionBlock >> "Answer the element at my position index. If I do not contain an >> element >> at index, answer the result of evaluating the argument, >> exceptionBlock." >> >> (index between: 1 and: self size) ifTrue: [^ self at: index]. >> ^ exceptionBlock value >> >> >> the thing is, that #at: primivite also doing a range checking and >> fails if index is invalid, so if index is valid, as result we >> performing a range checking twice instead of just once. >> >> Here the simple implementation how to make things faster: >> fat: index >> "Primitive. Assumes receiver is indexable. Answer the value of an >> indexable element in the receiver. Fail if the argument index is >> not an >> Integer or is out of bounds. Essential. See Object documentation >> whatIsAPrimitive. Read the class comment for a discussion about >> that the fact >> that the index can be a float." >> >> <primitive: 60> >> ^ #plopp >> >> fat: index ifAbsent: aBlock >> | x | >> x := (self fat: index). >> x == #plopp ifTrue: [ ^ aBlock value ]. >> ^ x >> >> And speedup is almost 2 times: >> >> [ 1000000 timesRepeat: [ #(1 2 4 5 56 67 67) at: 1 ifAbsent: nil ] ] >> timeToRun >> >> 39 >> >> [ 1000000 timesRepeat: [ #(1 2 4 5 56 67 67) at: 1 ifAbsent: nil ] ] >> timeToRun >> >> 20 >> >> Even when index is out of range, it is still much faster: >> >> [ 1000000 timesRepeat: [ #(1 2 4 5 56 67 67) at: 100 ifAbsent: nil ] ] >> timeToRun >> >> 35 >> >> [ 1000000 timesRepeat: [ #(1 2 4 5 56 67 67) fat: 100 ifAbsent: nil ] >> ] timeToRun >> >> 24 >> >> The problem, of course, that trick with #plopp is a dirty hack. >> Because if array include an #plopp object as element, it will report >> as it absent, >> instead of answering it. >> There is no way to ensure that any arbitrary object are never included >> as element in array, so this is no-go for generic replacement. >> But in controlled environment, when you know that none of arrays which >> you using with #fat:ifAbsent: will ever include #plopp (or pick your >> own unique object) >> it may be a good alternative. >> > > I've been thinking about this earlier and there's a much nicer and simpler > solution, though it requires vm changes :). The idea is to change primitive > 60 to work for 2 parameters too, so #at:ifAbsent: could also use the > primitive directly. There were a few changes about #at: recently (mirror > prims, cog), so I'm not sure it's still easy to change the primitive. > his is neat, but it wouldn't be an extension to primitive 60 but a new primitive that would ignore its top of stack. primitive 60 can operate with 2 args,when used as a mirror primitive, but then it ignores the receiver. Your usage would ignore the last argument. So choose a primitive number and I'll make it so... > > Levente > > > >> -- >> Best regards, >> Igor Stasenko. >> >> >> > -- best, Eliot

Nov. 2, 2011

Re: [Pharo-project] #at:ifAbsent: for Array(s) could be faster

by Herby VojÄÃk

what if fat would do different nasty trick, like <primitive:60> ^(thisContext callingContext argAt: 2) value ? (make up #callingContext and #argAt:, I just presume there is something like that...) The question is if it would be faster. -- View this message in context: http://forum.world.st/at-ifAbsent-for-Array-s-could-be-faster-tp3980183p398… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 2, 2011

Re: [Pharo-project] [Pharo-users] Brainstorming on the roadmap for first Pharo Consortium Engineer :)

by Max Leske

:D Interesting! On 02.11.2011, at 18:59, Igor Stasenko wrote: > On 2 November 2011 15:42, Max Leske <maxleske(a)gmail.com> wrote: >> Static git repository of the source code of Squeak and Pharo until Squeak version 4 and Pharo 1: >> http://scg.unibe.ch/research/Pharogenesis >> https://github.com/pharogenesis >> >> The source code layout (tree of directories and files) could probably be better. But I guess one could use it as proof of concept. >> > Ah, so you will be second one :) > I meant another project in mind. There was a ?thesis? of some student > to store all source code in sql database. instead of .changes and > .source files > integrated into an image. > >> Max >> >> >> >> On 02.11.2011, at 15:27, Igor Stasenko wrote: >> >>> How about new source code management? >>> >>> In terms of: >>> - better abstraction of source code access in image >>> - create a shared repository (database) , which can be used to browse >>> the history of all source code of Pharo and its predecessor up to >>> Squeak 1.0. >>> >>> We are discussed this idea couple times, and we already having some >>> pieces of puzzle , like Ring. >>> Also, there is already a project made by someone (forgot the name) , >>> who already storing all source code in database and managing it there. >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> > > > > -- > Best regards, > Igor Stasenko. >

Nov. 2, 2011

Re: [Pharo-project] #at:ifAbsent: for Array(s) could be faster

by Dave Mason

On Nov 2, 2011, at 14:21, Igor Stasenko wrote: > The problem, of course, that trick with #plopp is a dirty hack. > Because if array include an #plopp object as element, it will report > as it absent, instead of answering it. > There is no way to ensure that any arbitrary object are never included > as element in array, so this is no-go for generic replacement. > But in controlled environment, when you know that none of arrays which > you using with #fat:ifAbsent: will ever include #plopp (or pick your > own unique object) it may be a good alternative. If Array class initialize said: NonUserValue := Object new then #plopp can be replaced with NonUserValue and nobody can get at it unless they really intend to (e.g. by making Array be in their classPool). ../Dave

Nov. 2, 2011

Re: [Pharo-project] #at:ifAbsent: for Array(s) could be faster

by Levente Uzonyi

On Wed, 2 Nov 2011, Igor Stasenko wrote: > Here the original implementation, which Array inherits from > SequenceableCollection: > > at: index ifAbsent: exceptionBlock > "Answer the element at my position index. If I do not contain an element > at index, answer the result of evaluating the argument, exceptionBlock." > > (index between: 1 and: self size) ifTrue: [^ self at: index]. > ^ exceptionBlock value > > > the thing is, that #at: primivite also doing a range checking and > fails if index is invalid, so if index is valid, as result we > performing a range checking twice instead of just once. > > Here the simple implementation how to make things faster: > fat: index > "Primitive. Assumes receiver is indexable. Answer the value of an > indexable element in the receiver. Fail if the argument index is not an > Integer or is out of bounds. Essential. See Object documentation > whatIsAPrimitive. Read the class comment for a discussion about that the fact > that the index can be a float." > > <primitive: 60> > ^ #plopp > > fat: index ifAbsent: aBlock > | x | > x := (self fat: index). > x == #plopp ifTrue: [ ^ aBlock value ]. > ^ x > > And speedup is almost 2 times: > > [ 1000000 timesRepeat: [ #(1 2 4 5 56 67 67) at: 1 ifAbsent: nil ] ] timeToRun > > 39 > > [ 1000000 timesRepeat: [ #(1 2 4 5 56 67 67) at: 1 ifAbsent: nil ] ] timeToRun > > 20 > > Even when index is out of range, it is still much faster: > > [ 1000000 timesRepeat: [ #(1 2 4 5 56 67 67) at: 100 ifAbsent: nil ] ] timeToRun > > 35 > > [ 1000000 timesRepeat: [ #(1 2 4 5 56 67 67) fat: 100 ifAbsent: nil ] > ] timeToRun > > 24 > > The problem, of course, that trick with #plopp is a dirty hack. > Because if array include an #plopp object as element, it will report > as it absent, > instead of answering it. > There is no way to ensure that any arbitrary object are never included > as element in array, so this is no-go for generic replacement. > But in controlled environment, when you know that none of arrays which > you using with #fat:ifAbsent: will ever include #plopp (or pick your > own unique object) > it may be a good alternative. I've been thinking about this earlier and there's a much nicer and simpler solution, though it requires vm changes :). The idea is to change primitive 60 to work for 2 parameters too, so #at:ifAbsent: could also use the primitive directly. There were a few changes about #at: recently (mirror prims, cog), so I'm not sure it's still easy to change the primitive. Levente > > -- > Best regards, > Igor Stasenko. > >

Nov. 2, 2011