- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Small tool to edit bloc code

by StÃ©phane Ducasse

What do you mean by a block of code? With a syntax for method Point>>foo [ ] ? in that case I would use the syntax extension we did for coral based on petitparser. Stef On Nov 1, 2011, at 9:30 PM, Hilaire Fernandes wrote: > From DrGeo I would like the user to edit Smalltalk code in the form of > block of code. > The user interface I need is maninly to let the user write and compile > code. When compiled, DrGeo should get a notification to fetch the code > for internal use. > > What is the best candidate to do that ? > > Hilaire > > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > >

Nov. 3, 2011

Re: [Pharo-project] Moving a file

by Schwab,Wilhelm K

Make that "must have" Clearly (past) time to get some sleep. With that, happy Smalltalking to all, and good night :) ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] Sent: Wednesday, November 02, 2011 11:46 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Moving a file Sean, A couple of examples that might be helpful: (1) ping somebody and get the output: ^( PipeableOSProcess command:'ping ', host, ' -c 4' ) output. (2) from the selector name, I'm guessing that Dave was kind enough to send me this example in the days when I was completely (vs. now partially) clueless about the correct use of OSProcess: tryDave | gp | gp := PipeableOSProcess command:'gnuplot'. gp setNonBlockingOutput. gp exec:'set output ""'; exec:'set terminal png'; exec:'plot sin(x)'. (Delay forMilliseconds: 1000) wait. "allow gnuplot to send data" gp upToEnd inspect. "all available stdout data" gp errorUpToEnd inspect. "all available stderr data" gp close. FWIW, it appears that I use exclusively PipeableOSProcess. Note that you might need to send #closePipes. Sadly, my comments don't say *why* I added it (distinct from above examples), but since I'm only now finding them, the addition must of fixed the problem I was having. Searching the archives will likely turn up something with Dave explaining how and when to use it. Good luck. 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: Wednesday, November 02, 2011 9:58 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Moving a file Thanks, Bill. Schwab,Wilhelm K wrote: > > (1) Squeak's file system leaves a lot to be desired - give us time :) > I didn't mean that as a dig against Squeak, just as a shorthand for "the file system that traditionally has been included with Squeak" Schwab,Wilhelm K wrote: > > (2) It's not really missing, use OSProcess and mv. > Yes, I think this is the best option for now; but my inquiry was also a nudge to add this to the FS API ;-) Schwab,Wilhelm K wrote: > > (3) FileDirectory contains some copy and delete functionality that could > be combined > I want mv because of efficiency - cp-ing & then deleting 3.5gb takes what feels like about 30 seconds, where an mv feels instantaneous. Sean -- View this message in context: http://forum.world.st/Moving-a-file-tp3983916p3984022.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 3, 2011

Re: [Pharo-project] Moving a file

by Schwab,Wilhelm K

Sean, A couple of examples that might be helpful: (1) ping somebody and get the output: ^( PipeableOSProcess command:'ping ', host, ' -c 4' ) output. (2) from the selector name, I'm guessing that Dave was kind enough to send me this example in the days when I was completely (vs. now partially) clueless about the correct use of OSProcess: tryDave | gp | gp := PipeableOSProcess command:'gnuplot'. gp setNonBlockingOutput. gp exec:'set output ""'; exec:'set terminal png'; exec:'plot sin(x)'. (Delay forMilliseconds: 1000) wait. "allow gnuplot to send data" gp upToEnd inspect. "all available stdout data" gp errorUpToEnd inspect. "all available stderr data" gp close. FWIW, it appears that I use exclusively PipeableOSProcess. Note that you might need to send #closePipes. Sadly, my comments don't say *why* I added it (distinct from above examples), but since I'm only now finding them, the addition must of fixed the problem I was having. Searching the archives will likely turn up something with Dave explaining how and when to use it. Good luck. 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: Wednesday, November 02, 2011 9:58 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Moving a file Thanks, Bill. Schwab,Wilhelm K wrote: > > (1) Squeak's file system leaves a lot to be desired - give us time :) > I didn't mean that as a dig against Squeak, just as a shorthand for "the file system that traditionally has been included with Squeak" Schwab,Wilhelm K wrote: > > (2) It's not really missing, use OSProcess and mv. > Yes, I think this is the best option for now; but my inquiry was also a nudge to add this to the FS API ;-) Schwab,Wilhelm K wrote: > > (3) FileDirectory contains some copy and delete functionality that could > be combined > I want mv because of efficiency - cp-ing & then deleting 3.5gb takes what feels like about 30 seconds, where an mv feels instantaneous. Sean -- View this message in context: http://forum.world.st/Moving-a-file-tp3983916p3984022.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 3, 2011

Re: [Pharo-project] Moving a file

by Sean P. DeNigris

Thanks, Bill. Schwab,Wilhelm K wrote: > > (1) Squeak's file system leaves a lot to be desired - give us time :) > I didn't mean that as a dig against Squeak, just as a shorthand for "the file system that traditionally has been included with Squeak" Schwab,Wilhelm K wrote: > > (2) It's not really missing, use OSProcess and mv. > Yes, I think this is the best option for now; but my inquiry was also a nudge to add this to the FS API ;-) Schwab,Wilhelm K wrote: > > (3) FileDirectory contains some copy and delete functionality that could > be combined > I want mv because of efficiency - cp-ing & then deleting 3.5gb takes what feels like about 30 seconds, where an mv feels instantaneous. Sean -- View this message in context: http://forum.world.st/Moving-a-file-tp3983916p3984022.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 3, 2011

Re: [Pharo-project] Moving a file

by Schwab,Wilhelm K

Possible answers: (1) Squeak's file system leaves a lot to be desired - give us time :) (2) It's not really missing, use OSProcess and mv. (3) FileDirectory contains some copy and delete functionality that could be combined (1) is probably the most truthful answer; (3) the most helpful. OSProcess "really works." When I last checked, it did not work on Windows; consider ProcessWrapper on windows. HTH 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: Wednesday, November 02, 2011 9:09 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Moving a file 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] #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