February 2014 - Pharo-dev - lists.pharo.org

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

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

by Sebastian Sastre

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? ;)

Feb. 27, 2014

Re: [Pharo-dev] FLMaterializer Materialization error

by Max Leske

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. > > 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

Feb. 27, 2014

Re: [Pharo-dev] FLMaterializer Materialization error

by Lorenzo Baracchi

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 <mailto:baracchi.lorenzo@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. > > Best, > > > thanks > Lorenzo > > > > > -- > Mariano > http://marianopeck.wordpress.com

Feb. 27, 2014

Re: [Pharo-dev] Floats problem with SIXX between Pharo and GemStone

by Masashi UMEZAWA

Hi Mariano, How about just defining: SmallDouble >> sixxType ^'Float' SmallDouble >> sixxWriteValue ^self asFloat I'm not using GemStone right now, so maybe my assumption would be inaccurate. But just a quick answer. Regards, 2014-02-27 6:38 GMT+09:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi guys, > > When I export SmallDoubles with SIXX in GemStone it generates something like > this: > > <sixx.object sixx.id="15" sixx.name="close" sixx.type="SmallDouble" >>1.0000000000000000E-02</sixx.object> > > This is because "0.01 asString" -> '1.0000000000000000E-02' > > Then I want to load this in Pharo. So first problem is that of course > SmallDouble doesn't exist. So I did: > > aSixxShapeChangeStream shapeChangers at: #SmallDouble put: Float. > But then, SIXX use Float >> readFrom: aStream > "Answer a new Float as described on the stream, aStream." ^(super readFrom: > aStream) asFloat > > > So, of course " Float readFrom: '1.0000000000000000E-02' " -> 1.0 > > So my 0.01 in gemstone become 1.0 in Pharo.... > > Am I doing something wrong or this is expected? What is the best workaround? > > In GemStone I could print the SmallDouble in the XML with a method like > > Float >> xmlRepresentation > ^ String streamContents: > [:strm | self printOn: strm base: 10] > > Is this the correct approach? If true, I guess I should define: > > Float >> sixxContentOn: aStream indent: level context: dictionary aStream > nextPutAll: self xmlRepresentation > > > Thoughts? > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com -- [:masashi | ^umezawa]

Feb. 27, 2014