- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [fun] Sparkline in Pharo

by Henrik Johansen

On 26 Feb 2014, at 9:54 , Norbert Hartl <norbert(a)hartl.name> wrote: > Can you tell what these sparklines have to do with unicode? Itâs just a normal string containing Unicode characters being rendered. http://www.fileformat.info/info/unicode/block/block_elements/list.htm Though, imho, the information density is so low, itâs a bit of a stretch calling them spark lines. Cheers, Henry

Feb. 27, 2014

Re: [Pharo-dev] FLMaterializer Materialization error

by Henrik Johansen

On 27 Feb 2014, at 3:45 , Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Thu, Feb 27, 2014 at 11:32 AM, Max Leske <maxleske(a)gmail.com> wrote: > > On 27.02.2014, at 14:54, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> >> >> >> On Thu, Feb 27, 2014 at 10:48 AM, Lorenzo Baracchi <baracchi.lorenzo(a)gmail.com> wrote: >> Hi >> >> I was using FLMaterializer materializationFromFileNamed: filename to read fuel files. >> Until yesterday everything was fine, but today I updated Pharo and received the error "'Materialization error. Unexpected stream version 19 where it should be 193." >> >> I guess that a new version of fuel cannot (simply) read old versions files. >> >> This is the "default" exception. But maybe....between 1.9 and 1.9.2 the file format didn't change. Max? > > I think 1.9 to 1.9.3 should work without problems. I canât think of any changes to the file format. > > > An interesting idea for Fuel would be that for each released version, besides defining the version, we also define the list of previous versions that are known to work with this one. So for example, we could say that 1.9.3 should work ok up to 1.9. So upon materialization we check this info. This would be very cool. Of course, it is our responsibility (humans/developers) to define with which previous versions it should workâ¦ A versioning scheme that encodes much of the needed information directly is great for this. An example: X.Y.Z-[Dialect/Version] X - Major version changes, can not be expected to read streams of previous versions correctly (changed storage format for something) Y - Minor version changes, can be expected to read older versions, but not newer, correctly (added new capabilities to the format, such as new hooks etc.) Z - Internal changes/bugfixes, (no changes to the actual serialization format) [Dialect/Version] - Not needed for error recovery if classes of serialized instances are included, as that is better to use directly if encountering missing/incompatible definitions, but a nice bit of info to start from otherwise... Cheers, Henry

Feb. 27, 2014

Re: [Pharo-dev] iPad version does not work ?[SEC=UNCLASSIFIED]

by Esteban Lorenzano

yes On 26 Feb 2014, at 02:38, phil(a)highoctane.be wrote: > > Ah, yes, I saw that in the README but haven't yet been able to get the Sim to work. > > Have you? > > Phil > > > On Wed, Feb 26, 2014 at 9:01 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Yes it is. Take a look at the readme :) > > On 26 Feb 2014, at 08:28, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> You can make it work following the procedure: http://www.youtube.com/watch?v=7MNsUiCc5FQ&list=UUul18dYQnhOVMfYFg6YSK4A >> >> I don't know if you will have to mess with the Xcode project afterwards at this point but I remember I had to do weird things to get Cmake to work, due to some bugs in it. >> >> So, make sure you have the right version. >> >> What I didn't got working was the simulator version. Someone having it working at this point? >> >> Phil >

Feb. 27, 2014

Re: [Pharo-dev] Authorize upArrow in binary symbols

by Jan Vrany

On 27/02/14 14:58, Marcus Denker wrote: > > On 27 Feb 2014, at 13:56, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > >> On 24/02/14 19:06, Marcus Denker wrote: >> >>> >>> Pharo uses (right now) RBParser as the main Parserâ¦ in Pharo4 we will remove the old Parser (subclass of Scanner ;-), >>> on the TODO is to check if PetitParser can be used instead (but there are many open questions related to e.g. error handling, >>> speedâ¦) >> >> This is interesting for me. I would not go for petitparser personally. >> My experience, speaking of performance and error reporting, not so >> great. >> > Yesâ¦ sadly. Especially good error reporting is very crucial. Yet it would be so nice if Pharo would contain a hight level > reflective meta model of itâs own grammar! > >> I have one question: If you replace RBParser with green-field implementation, how would you deal with the rest of RB stuff? >> Refactorings, lint etc, which are all based of RBParser API? >> > The RBParser itself has a very small APIâ¦ âgive me an AST for a stringâ (#parseMethod: and #parseExpression:, in addition > #parseMethodPattern: and some special ones for rewrite rules (which is kind of a DSL on top of Smalltalk, these methods > already forward to RBPatternParser, a subclass of RBParser) Well, I meant RBParser and RB AST API, actually :-) > > In Pharo3 we already replaced all the references to Parser, Scanner and Compiler with a call to get the Opal compiler > facade. Wen we remove the old compiler in Pharo4, the next step is to do the same with *all* direct references > to RBParser. > (we could not yet do that as, when you enable the old compiler, you get the old AST backâ¦ for code generation it has > the same API, for refactoring not as the old AST does not support that. So for now we kept the code in a state that > you can disable Opal, yet refactoring still uses RBParser explicitly. When there is just one compiler, we can simplify > that even further). > > So after doing that, the actual implementation of the Parser can then be easily exchanged, the only thing it needs to do > is to create a RB AST. OK, so the idea is remove RBParser but keep all RBProgramNode classes? Jan

Feb. 27, 2014

Re: [Pharo-dev] [fun] Sparkline in Pharo

by Sebastian Sastre

haha yeah Iâve said is cute :D kind of great for really compact graph needs On Feb 27, 2014, at 11:41 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 27 Feb 2014, at 15:33, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >> >> On Feb 27, 2014, at 9:05 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>>> canât see applicability now but thatâs kind of cute :D >>> >>> That is where you are wrong, they are really useful as a simple, inline way to visualise some data. >>> >>> http://en.wikipedia.org/wiki/Sparkline >> >> Hey Sven, are you sure is a logic problem ("being wrongâ) and not a perception problem (âseeing applicability nowâ) that you fixed with your reference? >> >> ;) >> > > Yeah, right/wrong is not the issue. I am just trying to convince you to take a second look ;-) > > Here are two more references: > > http://images.businessweek.com/ss/09/06/0608_tufte/11.htm > http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR&topic_id=… > > It _is_ really cool. > > Sven > >

Feb. 27, 2014

Re: [Pharo-dev] Authorize upArrow in binary symbols

by Marcus Denker

On 27 Feb 2014, at 13:56, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > On 24/02/14 19:06, Marcus Denker wrote: > >> >> Pharo uses (right now) RBParser as the main Parserâ¦ in Pharo4 we will remove the old Parser (subclass of Scanner ;-), >> on the TODO is to check if PetitParser can be used instead (but there are many open questions related to e.g. error handling, >> speedâ¦) > > This is interesting for me. I would not go for petitparser personally. > My experience, speaking of performance and error reporting, not so > great. > Yesâ¦ sadly. Especially good error reporting is very crucial. Yet it would be so nice if Pharo would contain a hight level reflective meta model of itâs own grammar! > I have one question: If you replace RBParser with green-field implementation, how would you deal with the rest of RB stuff? > Refactorings, lint etc, which are all based of RBParser API? > The RBParser itself has a very small APIâ¦ âgive me an AST for a stringâ (#parseMethod: and #parseExpression:, in addition #parseMethodPattern: and some special ones for rewrite rules (which is kind of a DSL on top of Smalltalk, these methods already forward to RBPatternParser, a subclass of RBParser) In Pharo3 we already replaced all the references to Parser, Scanner and Compiler with a call to get the Opal compiler facade. Wen we remove the old compiler in Pharo4, the next step is to do the same with *all* direct references to RBParser. (we could not yet do that as, when you enable the old compiler, you get the old AST backâ¦ for code generation it has the same API, for refactoring not as the old AST does not support that. So for now we kept the code in a state that you can disable Opal, yet refactoring still uses RBParser explicitly. When there is just one compiler, we can simplify that even further). So after doing that, the actual implementation of the Parser can then be easily exchanged, the only thing it needs to do is to create a RB AST. The Opal compilationContext has already a #parserClass accessor that right now returns RBParser, but that any user can override. (this is not yet used so it might not work, but the machinery is there). Marcus

Feb. 27, 2014

Pharo 3.0 on Ubuntu 13.10

by Sven Van Caekenberghe

Pharo 3.0 on Ubuntu 13.10 The hacker experience: using ZeroConf to get Pharo 3.0 up and running in a blank Ubuntu 13.10 (32-bit) account in 1 minute flat. Doing some HTTP hacking in the next 5 minutes. Includes terminal headless execution as well. Please note that there are alternative ways to install and run Pharo [ http://www.pharo.org ]. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

Feb. 27, 2014

Re: [Pharo-dev] FLMaterializer Materialization error

by Mariano Martinez Peck

On Thu, Feb 27, 2014 at 11:32 AM, Max Leske <maxleske(a)gmail.com> wrote: > > On 27.02.2014, at 14:54, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > > On Thu, Feb 27, 2014 at 10:48 AM, Lorenzo Baracchi < > baracchi.lorenzo(a)gmail.com> wrote: > >> Hi >> >> I was using FLMaterializer materializationFromFileNamed: filename to read >> fuel files. >> Until yesterday everything was fine, but today I updated Pharo and >> received the error "'Materialization error. Unexpected stream version 19 >> where it should be 193." >> >> I guess that a new version of fuel cannot (simply) read old versions >> files. >> > > This is the "default" exception. But maybe....between 1.9 and 1.9.2 the > file format didn't change. Max? > > > I think 1.9 to 1.9.3 should work without problems. I can't think of any > changes to the file format. > > An interesting idea for Fuel would be that for each released version, besides defining the version, we also define the list of previous versions that are known to work with this one. So for example, we could say that 1.9.3 should work ok up to 1.9. So upon materialization we check this info. This would be very cool. Of course, it is our responsibility (humans/developers) to define with which previous versions it should work... Best, > > >> Is there a way to know in which version of fuel a file was written and >> use that version to read it? >> > > In the exception message itself. "'Materialization error. Unexpected > stream version 19 where it should be 193." > It says that in the current stream the version is 19 but the code now > expects 193. So you should load Fuel 1.9 to materialize those files. > > Best, > > > >> >> thanks >> Lorenzo >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Feb. 27, 2014

Re: [Pharo-dev] [fun] Sparkline in Pharo

by Sven Van Caekenberghe

On 27 Feb 2014, at 15:33, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > > On Feb 27, 2014, at 9:05 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>> canât see applicability now but thatâs kind of cute :D >> >> That is where you are wrong, they are really useful as a simple, inline way to visualise some data. >> >> http://en.wikipedia.org/wiki/Sparkline > > Hey Sven, are you sure is a logic problem ("being wrongâ) and not a perception problem (âseeing applicability nowâ) that you fixed with your reference? > > ;) > Yeah, right/wrong is not the issue. I am just trying to convince you to take a second look ;-) Here are two more references: http://images.businessweek.com/ss/09/06/0608_tufte/11.htm http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR&topic_id=… It _is_ really cool. Sven

Feb. 27, 2014

Re: [Pharo-dev] FLMaterializer Materialization error

by Max Leske

On 27.02.2014, at 15:26, Lorenzo Baracchi <baracchi.lorenzo(a)gmail.com> wrote: > On 2/27/14 2:54 PM, Mariano Martinez Peck wrote: >> >> >> >> On Thu, Feb 27, 2014 at 10:48 AM, Lorenzo Baracchi <baracchi.lorenzo(a)gmail.com> wrote: >> Hi >> >> I was using FLMaterializer materializationFromFileNamed: filename to read fuel files. >> Until yesterday everything was fine, but today I updated Pharo and received the error "'Materialization error. Unexpected stream version 19 where it should be 193." >> >> I guess that a new version of fuel cannot (simply) read old versions files. >> >> This is the "default" exception. But maybe....between 1.9 and 1.9.2 the file format didn't change. Max? >> >> Is there a way to know in which version of fuel a file was written and use that version to read it? >> >> In the exception message itself. "'Materialization error. Unexpected stream version 19 where it should be 193." >> It says that in the current stream the version is 19 but the code now expects 193. So you should load Fuel 1.9 to materialize those files. > so far so good. > > My goal was more about trying to avoid that error. Like asking to the FLMaterializer (or other) which version does a file have and then load the correspondent version of fuel. > For example: > version := FLMaterializer getVersionOfFileNamed: filename. > (ConfigurationOfFuel project version: version ) load. > materializerClass := Smalltalk at: #FLMaterializer. > ^materializerClass materializationFromFileNamed: filename. Thatâs an interesting idea! Will mostly not work though because the new versions often compensate for platform development. That means that older versions of Fuel will not correctly work with Pharo3 for instance because they donât know about Opal etc. Still, I think itâs a nice idea to be able to ask for the version of a Fuel file. Iâll open an issue for that. At the moment the version is encoded after the signature right at the beginning of the file and is not part of any special object that is materialized. Therefore, you best option is to read the first few bytes of the file and decode them manually as they would be with FLDecoder>>nextEncodedUint16. Cheers, Max >> >> Best, >> >> >> >> thanks >> Lorenzo >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >

Feb. 27, 2014