October 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Parsing Smalltalk Array/Object Literals

by GÃ¶ran Krampe

Hi guys! On 10/21/2012 03:12 PM, Mariano Martinez Peck wrote: > On Sun, Oct 21, 2012 at 2:38 PM, Igor Stasenko <siguctua(a)gmail.com > <mailto:siguctua@gmail.com>> wrote: > > On 21 October 2012 13:39, Denis Kudriashov <dionisiydk(a)gmail.com > <mailto:dionisiydk@gmail.com>> wrote: > > Hello > > > > > > 2012/10/21 Igor Stasenko <siguctua(a)gmail.com > <mailto:siguctua@gmail.com>> > >> > >> i now modelling a system logger (to replace .changes file), and > since > >> i having no better idea, > >> i'll try to use object literals for it. > > > > > > Do you see Deltas project? > > Sure i know about deltas. I was hacking it. :) > > > I think one of the proposals was .changes file replacement > > not exactly. it is more changeset replacement. > What i am doing is a bit orthogonal: it is a facility to recover > lost changes. > All of the sources will be held inside image. Well, Denis is right - Matthew was especially interested in that aspect (replacing the .changes file) IIRC. And I am not sure it is "a bit orthogonal". I mean, it's about logging changes to the image. The old ChangeSet implementation was not at all useful since a ChangeSet (contrary to popular belief) didn't actually *hold changes*. It just pointed to a method. But Deltas do completely "hold changes" - just like the .changes file does. Now, of course, the beauty of Deltas and its implementation of the various Change objects was that they held *all* state of the changes - enough to do undo. For example, if you did "aClass removeFromSystem" (pseudo code) - then it actually logged *all* code for aClass (enough to recreate it if you wanted to undo). > But one very common case to recover lost changes is when the image is > broken... so if you store the stuff in the image... IMHO a Delta which is backed by an external "store" of any kind (database, file using ehrm... Tirade? :) I created it for this *specific* use case!!!) - can totally replace a .changes file. regards, GÃ¶ran PS. Please do not reinvent *every* wheel we come across - if you are serious about making proper change logging - do it *at least* as capable as Deltas is/was.

Oct. 21, 2012

Re: [Pharo-project] Parsing Smalltalk Array/Object Literals

by StÃ©phane Ducasse

yes I know. We will fix that one of these days :) Stef On Oct 21, 2012, at 8:06 PM, Igor Stasenko wrote: > On 21 October 2012 16:18, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>> i now modelling a system logger (to replace .changes file), and since >>> i having no better idea, >>> i'll try to use object literals for it. >> >> >> Igor do not open too many projects :). Please finish the others. We want athens >> We are working on that with ezequiel and martin will probably help to get started with his phd. > > Don't worry, i wanted to do that during weekend :) > > I took a look at current stuff in CompiledMethod 'source code management' > and it makes me vomit: > > logMethodSource: aText forMethodWithNode: aCompiledMethodWithNode > inCategory: category withStamp: changeStamp notifying: requestor > > putSource: sourceStr fromParseNode: methodNode class: class category: catName > withStamp: changeStamp inFile: fileIndex priorMethod: priorMethod > > putSource: sourceStr fromParseNode: methodNode inFile: fileIndex > withPreamble: preambleBlock > > > it is just horrible: passing around tons of arguments, no delegation, > no encapsulation, spaghetti code. > >> It would be good if we could get rid of the >> >> ! >> !! >> delimiters >> >> for now ezequiel is just strong fuel objects but indeed having a textual format can be really important. >> >> Note that we will probably want to store complete refactorings so that we can reapply a logical changes or a set of physical modifications. >> >> Stef >> > > > -- > Best regards, > Igor Stasenko. >

Oct. 21, 2012

[Pharo-project] NativeBoost FFI

by Ciprian Teodorov

Hi guys, Over the weekend I had a look at NativeBoost FFI and I have enjoyed it. I really like this idea of taming the beast from high-level languages. However I ran into some problems with the number of arguments one can pass to a smaltalk method (it turns out to be 15 at max)... That bad for FFI especially when you want to interface with legacy c code without touching the C-stuff (header, object files, etc). In consequence I've hacked my way around this limitation by introduction of a new type of arguments that we can pass to callouts. I call these arguments "in object arguments". The idea isn't new and is very simple, instead of passing 20 arguments to your function just pass one an array with all the arguments you need. Where it turns interesting is that I think we can pass more than just an array we can pass real objects (think about ParameterObject) that hold in their instance variables the arguments we want. lets say that we want to call a function " int function(int x, int y)", now with the NativeBoost wrapper we will get a call something like function_x: x y: y <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self call: #( int function (int x, int y)) the idea is to replace x: y: with only one argument function: anArgument <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self call: #( int function (int anArgument@1, int anArgument@2)) or even function: aPoint <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self call: #( int function (int aPoint@x, int aPoint@y)) Yes this last example breaks the encapsulation a little bit by acceding directly to the instance variable of aPoint... but... well another example will be: function_arg1: a arg2: b <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self call: #( int function (int a@1, int a@2, int b@3, int b@1, int a@6)) Well that's all that I did this weekend. Attached to this mail you can find a file-out of these developments... they include: 1. the idea presented above 2. refactoring of NBFFICallout argument loader creation 3. a small "extension/fix" of the skipSpace method (in spec parser) to skip all separators not just spaces (think about a header definition with tabs) Well that's it folks, enjoy Cheers -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Oct. 21, 2012

Re: [Pharo-project] Parsing Smalltalk Array/Object Literals

by Dale Henrichs

Sven, I'm not asking about the parser for the literal array but the parser to parse the literal array itself, but I think you've answered my question (indirectly:) The original reason for going with JSON 9 months ago was that since GemStone does not have a accessible parser for Smalltalk syntax, I need to choose an export format for "objects" that included a portable parser for the syntax ... Presumably your implementation assumes the existence of a Smalltalk literal parser (I think that is what I was able to glean from Igor's mails) in which case I won't be able to use it (even if I thought it was usable from a readability standpoint:). Dale ----- Original Message ----- | From: "Sven Van Caekenberghe" <sven(a)stfx.eu> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Sunday, October 21, 2012 1:22:06 AM | Subject: Re: [Pharo-project] Parsing Smalltalk Array/Object Literals | | Yes, something is wrong with the ObjectLiterals repository on | SmalltalkHub, but I have no clue what. | | I made a copy in another place | | http://mc.stfx.eu/ObjectLiterals | | @Dale | | Of course ObjectLiteralsParser, is completely independent of any | other code, that is the whole idea. | And it is very small as well, it should be portable to any Smalltalk. | | @Igor | | The Symbol and Number syntax accepted by ObjectLiteralsParser is | artificially limited right now, as it was copied from STON. As long | as it is a proper subset of Smalltalk that does not strike me as a | problem. | | Anyway, the goal of the code is to allow for a more precise | discussion. | | Sven | | On 21 Oct 2012, at 02:36, Igor Stasenko <siguctua(a)gmail.com> wrote: | | > Me too: | > 'Could not load ObjectLiterals-SvenVanCaekenberghe.4.mcz: | > ZnHttpUnsuccessful: 404 Not Found' | > | > however, the monticello repository window shows it is there. | > | > Nicolas, any clues what going on? | | -- | Sven Van Caekenberghe | http://stfx.eu | Smalltalk is the Red Pill | | | | |

Oct. 21, 2012

Re: [Pharo-project] Parsing Smalltalk Array/Object Literals

by Igor Stasenko

On 21 October 2012 16:18, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> i now modelling a system logger (to replace .changes file), and since >> i having no better idea, >> i'll try to use object literals for it. > > > Igor do not open too many projects :). Please finish the others. We want athens > We are working on that with ezequiel and martin will probably help to get started with his phd. Don't worry, i wanted to do that during weekend :) I took a look at current stuff in CompiledMethod 'source code management' and it makes me vomit: logMethodSource: aText forMethodWithNode: aCompiledMethodWithNode inCategory: category withStamp: changeStamp notifying: requestor putSource: sourceStr fromParseNode: methodNode class: class category: catName withStamp: changeStamp inFile: fileIndex priorMethod: priorMethod putSource: sourceStr fromParseNode: methodNode inFile: fileIndex withPreamble: preambleBlock it is just horrible: passing around tons of arguments, no delegation, no encapsulation, spaghetti code. > It would be good if we could get rid of the > > ! > !! > delimiters > > for now ezequiel is just strong fuel objects but indeed having a textual format can be really important. > > Note that we will probably want to store complete refactorings so that we can reapply a logical changes or a set of physical modifications. > > Stef > -- Best regards, Igor Stasenko.

Oct. 21, 2012

Re: [Pharo-project] Parsing Smalltalk Array/Object Literals

by Igor Stasenko

On 21 October 2012 15:12, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Sun, Oct 21, 2012 at 2:38 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 21 October 2012 13:39, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> > Hello >> > >> > >> > 2012/10/21 Igor Stasenko <siguctua(a)gmail.com> >> >> >> >> i now modelling a system logger (to replace .changes file), and since >> >> i having no better idea, >> >> i'll try to use object literals for it. >> > >> > >> > Do you see Deltas project? >> >> Sure i know about deltas. I was hacking it. :) >> >> > I think one of the proposals was .changes file replacement >> >> not exactly. it is more changeset replacement. >> What i am doing is a bit orthogonal: it is a facility to recover lost >> changes. >> All of the sources will be held inside image. >> > > But one very common case to recover lost changes is when the image is > broken... so if you store the stuff in the image... > the log can be opened by another image. And doing image backups also helps. And recovering image also possible :) >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Best regards, Igor Stasenko.

Oct. 21, 2012

Re: [Pharo-project] Doits not logged to .changes file

by Noury Bouraqadi

It's a very old issue. Older than Pharo itself. Noury On 21 oct. 2012, at 12:02, Igor Stasenko wrote: > just found that they are not logger.. > is it known issue of i am lucky one > (Pharo2.0a Latest update: #20267) > > (tried 20351 image, same story) > -- > Best regards, > Igor Stasenko. > Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --

Oct. 21, 2012

Re: [Pharo-project] how can I get a 20 image without Nautilus and RB?

by Mariano Martinez Peck

To answer your question: right now, there is no way I am aware of. The only thing you may want to try is to manually unload the packages :( On Sun, Oct 21, 2012 at 4:35 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi guys > > Since now Metacello is loaded and I would like to check the new > configurationOfRefactoringBrowser, Nautilus and many othersâ¦ :) > I would like to know if there is an image that I can use to test them. > > In addition, as you guess, I would like that the integration server is > loading them for us from the configurations :) > Remember we want a modular and small system. > > Esteban (I know that you do not have enough time to work on what we both > want :). > We will have to resurrect this project :) > > Stef > -- Mariano http://marianopeck.wordpress.com

Oct. 21, 2012

[Pharo-project] how can I get a 20 image without Nautilus and RB?

by StÃ©phane Ducasse

Hi guys Since now Metacello is loaded and I would like to check the new configurationOfRefactoringBrowser, Nautilus and many othersâ¦ :) I would like to know if there is an image that I can use to test them. In addition, as you guess, I would like that the integration server is loading them for us from the configurations :) Remember we want a modular and small system. Esteban (I know that you do not have enough time to work on what we both want :). We will have to resurrect this project :) Stef

Oct. 21, 2012

Re: [Pharo-project] Spec Text Completion / focus

by Benjamin

Soon it will be delegated to Keymapping :) Thank you for the feedback :) Ben On Oct 20, 2012, at 7:41 PM, Sean P. DeNigris wrote: > In Pharo 1.4, with Spec 1.1 loaded, text widgets seem to have source code > completion by default. This doesn't seem right. > > Also, to set the tab order: > myFieldModel > isEventForNextFocusBlock: [ :evt | evt keyCharacter = Character tab ]. > self focusOrder add: myFieldModel. > > The block is pretty cool because it's so flexible, but it seems like most of > the time, there would be one way to move through a form e.g. tab for each > next field. In that most common simple case, it's a little clunky to have to > specify the block for each widget. Maybe the widgets should just delegate to > the parent? Also, maybe #nextFocusBlock: would be a kinder name for > #isEventForNextFocusBlock: :) > > Whatever we decide, I recommend adding the focus stuff to the next round of > documentation, because it doesn't seem very obvious. > > Cheers, > Sean > > > > -- > View this message in context: http://forum.world.st/Spec-Text-Completion-focus-tp4652161.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Oct. 21, 2012