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

Re: [Pharo-project] Yet another Notation format: Object literals

by Igor Stasenko

On 19 October 2012 16:31, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Igor, > > This is a very nice and elegant expression (of a variation) of the Array literal idea. > Thanks a lot for taking the effort to implement and share it. > > I think that a formal specification and a standalone parser that does not depend on the builtin compiler is also needed. > That would mean that we have to define all primitive types. Minimally I can see these: > > - nil > - Boolean > - Integer > - Symbol > - Float > - String > > What with escaping unprintable characters ? well, this is easy: implement String>>asObjectLiteral to answer 'escaped representation of string' and String>>fromObjectLiteral to unescape it back. so, you probably won't need to bother with escaping in parser (parser will parse human-readable chars) > What with complex symbols ? like what? > What with fractions ? just implement conversion methods for it and that's it > What with human readable/writeable representations for Date, Time, DateAndTime ? same story :) > > The classnames currently match one-to-one to classes, in the light of cross dialect compatibility and namespaces a mapping might be needed. > yeah.. but that's not a big deal , right? you can always replace "Smalltalk at: symbol " with something like "Smalltalk at: (ObjectLiteralMapping of: symbol)" or whatever :) and, of course if no class found, you can still play nicely, i.e.: (Smalltalk at: classname ifAbsent: [ ^ ObjectLiteralNoMapping for: literal ] ) (see the implementation of Array>>fromObjectLiteral) > Sven > > PS: provided we can agree and formally define the above, I might be interested in trying to write a parser ;-) > :) -- Best regards, Igor Stasenko.

Oct. 19, 2012

Re: [Pharo-project] Yet another Notation format: Object literals

by Igor Stasenko

On 19 October 2012 14:11, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi Igor, > > I like this very much. > > When you say: >> Object>>#asObjectLiteral to be a subclass responsibility. > > I am not convinced this has to be the case. In my opinion, #asObjectLiteral should be a replacement of #storeString. And #storeString is defined on Object and it is not abstract. > well, it is easy to implement generic one (iterate over all inst vars, and then over all indexable vars, and put them into array.. ) but main point for not providing default one is to make conversion explicit i.e.: - not all objects can be represented as literals - only those, which do, should implement conversion methods. but i agree , this is arguable. As long as you using objects which provide own converters, (so a generic one never takes place), you don't have to worry about it. > According to the object you are converting into a string, #storeString may produce code that exceed the amount of literal you can have in a method. Maybe #asObjectLiteral could split the result into chunk that can be individually embedded in a single method. not the case. #( whatever (no matter how deeply nested) ) is a _single_ literal. > > I agree with you that #asObjectLiteral should be overridden. It would be cool to have Class>> asObjectLiteral > > How large your parser is? > if you asking this quesiton, you miss the point totally. there is no parser except smalltalk parser. :) What parser you need to parse: #( Array 1 2 3) ? then i converting it to #(1 2 3) but that is has nothing to do with parsing: Array>>fromObjectLiteral "Convert receiver back from object literal representation. Arrays is always holding a class name as first element, dispatch to the class to perform a conversion " ^ (Smalltalk globals at: self first) fromObjectLiteral: self Collection class>>fromObjectLiteral: objLiteralArray ^ self withAll: (objLiteralArray allButFirst collect: [:each | each fromObjectLiteral ] ) So, if that answering your question, those two methods is 'how large' my parser is :) > Alexandre > > > On Oct 19, 2012, at 8:09 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> Hi, >> as i promised before, here the simple smalltalk-based literal format. >> It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to >> have separate parser (a normal smalltalk parser used for that). >> >> The idea is quite simple: >> you can tell any object to represent itself as an 'object literal' , >> for example: >> >> (1@3) asObjectLiteral >> --> #(#Point 1 3) >> >> { 1@2. 3@4. true. false . nil } asObjectLiteral >> >> -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) >> >> (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) asObjectLiteral >> -> >> #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') >> >> Next thing, you can 'pretty-print' it (kinda): >> >> #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral >> >> '#(#Dictionary >> 1 >> (#Array 1 2 3) >> ''foo'' ''bar'')' >> >> >> and sure thing, you can do reverse conversion: >> >> '#(#Dictionary >> 1 >> (#Array 1 2 3) >> ''foo'' ''bar'')' parseAsObjectLiteral >> >> a Dictionary('foo'->'bar' 1->#(1 2 3) ) >> >> Initially, i thought that it could be generic (by implementing default >> Object>>#asObjectLiteral), >> but then after discussing it with others, we decided to leave >> >> Object>>#asObjectLiteral to be a subclass responsibility. >> So, potentially the format allows to represent any object(s) as >> literals, except from circular referencing objects, of course. >> >> The implementation is fairly simple, as you may guess and contains no >> new classes, but just extension methods here and there. >> >> Take it with grain and salt, since it is just a small proof of >> concept. (And if doing it for real it may need some changes etc). >> Since i am far from areas right now, where it can be used, i don't >> want to pursue it further or advocate if this is the right way to do >> things. >> Neither i having a public repository for this project.. >> >> So, if there anyone who willing to pick it up and pursue the idea >> further, please feel free to do so and make a public repository for >> project. >> >> >> -- >> Best regards, >> Igor Stasenko. >> <ObjectLiterals-IgorStasenko.1.mcz> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- Best regards, Igor Stasenko.

Oct. 19, 2012

Re: [Pharo-project] Yet another Notation format: Object literals

by Sven Van Caekenberghe

Dale, We have a web app where users sometimes have to enter some short pieces of JSON - because we were lazy and did not provide a proper interface ;-) You wouldn't believe in how many ways they make syntax errors and don't understand it ! Alternating key value elements is not that worse than key:value or key->value IMO, but it is a bit worse, agreed. The advantage is that you don't need extra syntax/semantics. Also, we could agree on #(#Time '15:24:01Z') #(#Date '2012-10-19') #(#DateAndTime '2012-10-19T15:24:01Z') with dashed and colons being optional. Sven BTW: Is the # in front of Symbols needed ? On 19 Oct 2012, at 16:55, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Igor, > > I'm afraid that your notation is not very friendly to humans ... a computer can keep track of the key value pairs in the literal dictionary, but a human will fail very quickly... > > The appeal of JSON (and STON) is that the output is readable by mere mortals: > > (JavaScript Object Notation) is a lightweight > data-interchange format. It is easy for humans to > read and write. > > What we're missing from Smalltalk is a literal dictionary or literal map syntax ... without that I'm afraid that for human friendly, lightweight notations we have to step away from the Smalltalk syntax - STON does this very nicely BTW... > > Dale > > ----- Original Message ----- > | From: "Igor Stasenko" <siguctua(a)gmail.com> > | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > | Sent: Friday, October 19, 2012 4:09:22 AM > | Subject: [Pharo-project] Yet another Notation format: Object literals > | > | Hi, > | as i promised before, here the simple smalltalk-based literal format. > | It based on smalltalk syntax, and so, unlike JSON, it doesn't needs > | to > | have separate parser (a normal smalltalk parser used for that). > | > | The idea is quite simple: > | you can tell any object to represent itself as an 'object literal' , > | for example: > | > | (1@3) asObjectLiteral > | --> #(#Point 1 3) > | > | { 1@2. 3@4. true. false . nil } asObjectLiteral > | > | -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) > | > | (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) > | asObjectLiteral > | -> > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') > | > | Next thing, you can 'pretty-print' it (kinda): > | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral > | > | '#(#Dictionary > | 1 > | (#Array 1 2 3) > | ''foo'' ''bar'')' > | > | > | and sure thing, you can do reverse conversion: > | > | '#(#Dictionary > | 1 > | (#Array 1 2 3) > | ''foo'' ''bar'')' parseAsObjectLiteral > | > | a Dictionary('foo'->'bar' 1->#(1 2 3) ) > | > | Initially, i thought that it could be generic (by implementing > | default > | Object>>#asObjectLiteral), > | but then after discussing it with others, we decided to leave > | > | Object>>#asObjectLiteral to be a subclass responsibility. > | So, potentially the format allows to represent any object(s) as > | literals, except from circular referencing objects, of course. > | > | The implementation is fairly simple, as you may guess and contains no > | new classes, but just extension methods here and there. > | > | Take it with grain and salt, since it is just a small proof of > | concept. (And if doing it for real it may need some changes etc). > | Since i am far from areas right now, where it can be used, i don't > | want to pursue it further or advocate if this is the right way to do > | things. > | Neither i having a public repository for this project.. > | > | So, if there anyone who willing to pick it up and pursue the idea > | further, please feel free to do so and make a public repository for > | project. > | > | > | -- > | Best regards, > | Igor Stasenko. > | >

Oct. 19, 2012

Re: [Pharo-project] Yet another Notation format: Object literals

by Dale Henrichs

Igor, I'm afraid that your notation is not very friendly to humans ... a computer can keep track of the key value pairs in the literal dictionary, but a human will fail very quickly... The appeal of JSON (and STON) is that the output is readable by mere mortals: (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. What we're missing from Smalltalk is a literal dictionary or literal map syntax ... without that I'm afraid that for human friendly, lightweight notations we have to step away from the Smalltalk syntax - STON does this very nicely BTW... Dale ----- Original Message ----- | From: "Igor Stasenko" <siguctua(a)gmail.com> | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> | Sent: Friday, October 19, 2012 4:09:22 AM | Subject: [Pharo-project] Yet another Notation format: Object literals | | Hi, | as i promised before, here the simple smalltalk-based literal format. | It based on smalltalk syntax, and so, unlike JSON, it doesn't needs | to | have separate parser (a normal smalltalk parser used for that). | | The idea is quite simple: | you can tell any object to represent itself as an 'object literal' , | for example: | | (1@3) asObjectLiteral | --> #(#Point 1 3) | | { 1@2. 3@4. true. false . nil } asObjectLiteral | | -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) | | (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) | asObjectLiteral | -> | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') | | Next thing, you can 'pretty-print' it (kinda): | | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral | | '#(#Dictionary | 1 | (#Array 1 2 3) | ''foo'' ''bar'')' | | | and sure thing, you can do reverse conversion: | | '#(#Dictionary | 1 | (#Array 1 2 3) | ''foo'' ''bar'')' parseAsObjectLiteral | | a Dictionary('foo'->'bar' 1->#(1 2 3) ) | | Initially, i thought that it could be generic (by implementing | default | Object>>#asObjectLiteral), | but then after discussing it with others, we decided to leave | | Object>>#asObjectLiteral to be a subclass responsibility. | So, potentially the format allows to represent any object(s) as | literals, except from circular referencing objects, of course. | | The implementation is fairly simple, as you may guess and contains no | new classes, but just extension methods here and there. | | Take it with grain and salt, since it is just a small proof of | concept. (And if doing it for real it may need some changes etc). | Since i am far from areas right now, where it can be used, i don't | want to pursue it further or advocate if this is the right way to do | things. | Neither i having a public repository for this project.. | | So, if there anyone who willing to pick it up and pursue the idea | further, please feel free to do so and make a public repository for | project. | | | -- | Best regards, | Igor Stasenko. |

Oct. 19, 2012

Re: [Pharo-project] RPackage by-hand code

by Goubier Thierry

Hi Esteban, Thanks, it worked perfectly! One more step towards 2.0 beta status, and a good start for the week-end :) Thierry Le 19/10/2012 16:32, Esteban Lorenzano a Ã©crit : > Hi, > > I have a fix (for the lost packages issue), but I cannot integrate now because google is in read-only mode. > In the mean time, you can > > merge issue 6834 (slice is in PharoInbox) > > and execute: > > MCWorkingCopy allManagers do: #packageSet. > RPackageOrganizer initialize. > > Esteban > > On Oct 19, 2012, at 10:51 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> Le 19/10/2012 09:14, StÃ©phane Ducasse a Ã©crit : >>> >>> On Oct 18, 2012, at 11:37 PM, GOUBIER Thierry wrote: >>> >>>> Hum. I don't know how to easily reproduce the bug, but you may see the result. >>>> >>>> Take the last 2.0 image for download, open a Monticello browser, select one of the Refactoring-Tests-* package, do browse package, and look at what's inside the browser. >>> >>> Yes I just found exactly the same problems. >>> I could not find the Refactoring-Tests and the classes are in the system but Nautilus is not able to show them. >>> Probably because RPackage sync is wrong. >> >> Ok, I think I have a way to reproduce it, or to check if it happens in another setup than mine: >> >> http://code.google.com/p/pharo/issues/detail?id=6834#c3 >> >> On a 20351 default image executing >> >> RPackageOrganizer initialize. >> >> Will empty the following packages: >> >> Hudson* >> Metacello* >> >> Look at the result of >> >> Smalltalk allClasses select: [:each | (RPackageOrganizer default packageOf: each) packageName = RPackage defaultPackageName ] >> >>>> Can also be checked through: >>>> ReleaseTest>>testUnpackagedClasses >>>> : unpackagesClasses isn't empty. >>>> >>>> I believed it happened in a RPackageOrganizer initialize in one of the recent updates, but why? It does not happens everytime with my packages: sometimes it's one, another time it's three packages, and yet another time it's none. Esteban has my image, but it seems hard to reproduce. >>> >>> Ok thanks we will have a look. >> >> Thanks as well for trying to solve that. >> >> Thierry >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Oct. 19, 2012

Re: [Pharo-project] RPackage by-hand code

by Esteban Lorenzano

Hi, I have a fix (for the lost packages issue), but I cannot integrate now because google is in read-only mode. In the mean time, you can merge issue 6834 (slice is in PharoInbox) and execute: MCWorkingCopy allManagers do: #packageSet. RPackageOrganizer initialize. Esteban On Oct 19, 2012, at 10:51 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 19/10/2012 09:14, StÃ©phane Ducasse a Ã©crit : >> >> On Oct 18, 2012, at 11:37 PM, GOUBIER Thierry wrote: >> >>> Hum. I don't know how to easily reproduce the bug, but you may see the result. >>> >>> Take the last 2.0 image for download, open a Monticello browser, select one of the Refactoring-Tests-* package, do browse package, and look at what's inside the browser. >> >> Yes I just found exactly the same problems. >> I could not find the Refactoring-Tests and the classes are in the system but Nautilus is not able to show them. >> Probably because RPackage sync is wrong. > > Ok, I think I have a way to reproduce it, or to check if it happens in another setup than mine: > > http://code.google.com/p/pharo/issues/detail?id=6834#c3 > > On a 20351 default image executing > > RPackageOrganizer initialize. > > Will empty the following packages: > > Hudson* > Metacello* > > Look at the result of > > Smalltalk allClasses select: [:each | (RPackageOrganizer default packageOf: each) packageName = RPackage defaultPackageName ] > >>> Can also be checked through: >>> ReleaseTest>>testUnpackagedClasses >>> : unpackagesClasses isn't empty. >>> >>> I believed it happened in a RPackageOrganizer initialize in one of the recent updates, but why? It does not happens everytime with my packages: sometimes it's one, another time it's three packages, and yet another time it's none. Esteban has my image, but it seems hard to reproduce. >> >> Ok thanks we will have a look. > > Thanks as well for trying to solve that. > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

Oct. 19, 2012

Re: [Pharo-project] Yet another Notation format: Object literals

by Sven Van Caekenberghe

Hi Igor, This is a very nice and elegant expression (of a variation) of the Array literal idea. Thanks a lot for taking the effort to implement and share it. I think that a formal specification and a standalone parser that does not depend on the builtin compiler is also needed. That would mean that we have to define all primitive types. Minimally I can see these: - nil - Boolean - Integer - Symbol - Float - String What with escaping unprintable characters ? What with complex symbols ? What with fractions ? What with human readable/writeable representations for Date, Time, DateAndTime ? The classnames currently match one-to-one to classes, in the light of cross dialect compatibility and namespaces a mapping might be needed. Sven PS: provided we can agree and formally define the above, I might be interested in trying to write a parser ;-) > Hi, > as i promised before, here the simple smalltalk-based literal format. > It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to > have separate parser (a normal smalltalk parser used for that). > > The idea is quite simple: > you can tell any object to represent itself as an 'object literal' , > for example: > > (1@3) asObjectLiteral > --> #(#Point 1 3) > > { 1@2. 3@4. true. false . nil } asObjectLiteral > > -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) > > (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) asObjectLiteral > -> > #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') > > Next thing, you can 'pretty-print' it (kinda): > > #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral > > '#(#Dictionary > 1 > (#Array 1 2 3) > ''foo'' ''bar'')' > > > and sure thing, you can do reverse conversion: > > '#(#Dictionary > 1 > (#Array 1 2 3) > ''foo'' ''bar'')' parseAsObjectLiteral > > a Dictionary('foo'->'bar' 1->#(1 2 3) ) > > Initially, i thought that it could be generic (by implementing default > Object>>#asObjectLiteral), > but then after discussing it with others, we decided to leave > > Object>>#asObjectLiteral to be a subclass responsibility. > So, potentially the format allows to represent any object(s) as > literals, except from circular referencing objects, of course. > > The implementation is fairly simple, as you may guess and contains no > new classes, but just extension methods here and there. > > Take it with grain and salt, since it is just a small proof of > concept. (And if doing it for real it may need some changes etc). > Since i am far from areas right now, where it can be used, i don't > want to pursue it further or advocate if this is the right way to do > things. > Neither i having a public repository for this project.. > > So, if there anyone who willing to pick it up and pursue the idea > further, please feel free to do so and make a public repository for > project. > > > -- > Best regards, > Igor Stasenko. > <ObjectLiterals-IgorStasenko.1.mcz>

Oct. 19, 2012

Re: [Pharo-project] [OT] Lars Bak on VM's

by Esteban Lorenzano

- do you have somethign like JSON? - well, we have this class called "Map" :D On Oct 19, 2012, at 2:00 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 19 October 2012 10:03, Torsten Bergmann <astares(a)gmx.de> wrote: >> Lars Bak presents several language virtual machines (Self, Strongtalk, Hotspot), why they matter and how they influenced V8 and Dart. >> >> http://www.infoq.com/presentations/Performance-V8-Dart >> >> I agree when he states "I like Smalltalk" ;) >> > > and i second his statement, about "most people find it hard to write > concurrent code" :) > > -- > Best regards, > Igor Stasenko. >

Oct. 19, 2012

Re: [Pharo-project] Yet another Notation format: Object literals

by Alexandre Bergel

Hi Igor, I like this very much. When you say: > Object>>#asObjectLiteral to be a subclass responsibility. I am not convinced this has to be the case. In my opinion, #asObjectLiteral should be a replacement of #storeString. And #storeString is defined on Object and it is not abstract. According to the object you are converting into a string, #storeString may produce code that exceed the amount of literal you can have in a method. Maybe #asObjectLiteral could split the result into chunk that can be individually embedded in a single method. I agree with you that #asObjectLiteral should be overridden. It would be cool to have Class>> asObjectLiteral How large your parser is? Alexandre On Oct 19, 2012, at 8:09 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hi, > as i promised before, here the simple smalltalk-based literal format. > It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to > have separate parser (a normal smalltalk parser used for that). > > The idea is quite simple: > you can tell any object to represent itself as an 'object literal' , > for example: > > (1@3) asObjectLiteral > --> #(#Point 1 3) > > { 1@2. 3@4. true. false . nil } asObjectLiteral > > -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) > > (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) asObjectLiteral > -> > #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') > > Next thing, you can 'pretty-print' it (kinda): > > #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral > > '#(#Dictionary > 1 > (#Array 1 2 3) > ''foo'' ''bar'')' > > > and sure thing, you can do reverse conversion: > > '#(#Dictionary > 1 > (#Array 1 2 3) > ''foo'' ''bar'')' parseAsObjectLiteral > > a Dictionary('foo'->'bar' 1->#(1 2 3) ) > > Initially, i thought that it could be generic (by implementing default > Object>>#asObjectLiteral), > but then after discussing it with others, we decided to leave > > Object>>#asObjectLiteral to be a subclass responsibility. > So, potentially the format allows to represent any object(s) as > literals, except from circular referencing objects, of course. > > The implementation is fairly simple, as you may guess and contains no > new classes, but just extension methods here and there. > > Take it with grain and salt, since it is just a small proof of > concept. (And if doing it for real it may need some changes etc). > Since i am far from areas right now, where it can be used, i don't > want to pursue it further or advocate if this is the right way to do > things. > Neither i having a public repository for this project.. > > So, if there anyone who willing to pick it up and pursue the idea > further, please feel free to do so and make a public repository for > project. > > > -- > Best regards, > Igor Stasenko. > <ObjectLiterals-IgorStasenko.1.mcz> -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 19, 2012

Re: [Pharo-project] [OT] Lars Bak on VM's

by Alexandre Bergel

Thanks Torsten for the link cheers, Alexandre On Oct 19, 2012, at 5:03 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Lars Bak presents several language virtual machines (Self, Strongtalk, Hotspot), why they matter and how they influenced V8 and Dart. > > http://www.infoq.com/presentations/Performance-V8-Dart > > I agree when he states "I like Smalltalk" ;) > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 19, 2012