- Pharo-users - lists.pharo.org

Re: [Pharo-users] Storing test data in methods

by Mariano Martinez Peck

Norbert, does the model have lots of strings? Because if so you can try using the compression. It may increase speed. There is always a trade off between the additional time of compressing/uncompressing. But if the model has quite an amount of strings, since writing to disk is also slow and the final stream would be smaller, it could be faster. Cheers, On Tue, Jul 23, 2013 at 9:40 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 23.07.2013 um 14:23 schrieb "jtuchel(a)objektfabrik.de" < > jtuchel(a)objektfabrik.de>: > > > Norbert, > > > > Am 23.07.13 14:07, schrieb Norbert Hartl: > >> Joachim, > >> > >> I'm aware that you can do serialization/deserialization yourself. I was > asking for something to help along the way because a have quite some model > classes to cover. I want a more generalized way of doing it. As often I > really think about things _after_ I've sent the mail :) > > > > We seem to have a lot in common here. Regard it this way: sending the > mail made you think again. So the mail itself was all but useless. > >> I think I have to options: > >> > >> 1. The most generic one is serializing into Fuel and compile the > ByteArray in a method. > >> 2. The most readable one will be using STON and compiling the STON > string into a method > >> > >> Maybe I should try both. > > I'd be very interested in what you find. I guess Fuel is smaller and > maybe even faster. STON, OTOH, is much friendlier for comparing versions > and such. > > > Well, I can't look at the method but I don't find ByteArrays not that > interesting anyway. So the actual size of the serialized byte array is > > (ByteArray streamContents: [:stream| > FLSerializer serialize: TCAP current model on: stream ]) > size > > is 237445 Bytes. Serializing > > [ MAPExampleModels class compile: 'tcap > ^ ', (ByteArray streamContents: [:stream| > FLSerializer serialize: TCAP current model on: stream ]) > storeString ] timeToRun > > took 647 ms > > but > > [FLMaterializer materializeFromByteArray: MAPExampleModels tcap] timeToRun > > took only 30ms. Basically I'm not fond of putting too much binary stuff > into compiled methods but it is the most easy and reliable way of providing > tests with test data. The whole grammar is stored in methods as well. It is > text butâ¦. > > I think I stay with it for a while. > > Norbert > > > > -- Mariano http://marianopeck.wordpress.com

July 23, 2013

Re: [Pharo-users] Storing test data in methods

by Norbert Hartl

Am 23.07.2013 um 14:23 schrieb "jtuchel(a)objektfabrik.de" <jtuchel(a)objektfabrik.de>: > Norbert, > > Am 23.07.13 14:07, schrieb Norbert Hartl: >> Joachim, >> >> I'm aware that you can do serialization/deserialization yourself. I was asking for something to help along the way because a have quite some model classes to cover. I want a more generalized way of doing it. As often I really think about things _after_ I've sent the mail :) > > We seem to have a lot in common here. Regard it this way: sending the mail made you think again. So the mail itself was all but useless. >> I think I have to options: >> >> 1. The most generic one is serializing into Fuel and compile the ByteArray in a method. >> 2. The most readable one will be using STON and compiling the STON string into a method >> >> Maybe I should try both. > I'd be very interested in what you find. I guess Fuel is smaller and maybe even faster. STON, OTOH, is much friendlier for comparing versions and such. > Well, I can't look at the method but I don't find ByteArrays not that interesting anyway. So the actual size of the serialized byte array is (ByteArray streamContents: [:stream| FLSerializer serialize: TCAP current model on: stream ]) size is 237445 Bytes. Serializing [ MAPExampleModels class compile: 'tcap ^ ', (ByteArray streamContents: [:stream| FLSerializer serialize: TCAP current model on: stream ]) storeString ] timeToRun took 647 ms but [FLMaterializer materializeFromByteArray: MAPExampleModels tcap] timeToRun took only 30ms. Basically I'm not fond of putting too much binary stuff into compiled methods but it is the most easy and reliable way of providing tests with test data. The whole grammar is stored in methods as well. It is text butâ¦. I think I stay with it for a while. Norbert

July 23, 2013

Re: [Pharo-users] Storing test data in methods

by Norbert Hartl

Am 23.07.2013 um 14:23 schrieb "jtuchel(a)objektfabrik.de" <jtuchel(a)objektfabrik.de>: > Norbert, > > Am 23.07.13 14:07, schrieb Norbert Hartl: >> Joachim, >> >> I'm aware that you can do serialization/deserialization yourself. I was asking for something to help along the way because a have quite some model classes to cover. I want a more generalized way of doing it. As often I really think about things _after_ I've sent the mail :) > > We seem to have a lot in common here. Regard it this way: sending the mail made you think again. So the mail itself was all but useless. >> I think I have to options: >> >> 1. The most generic one is serializing into Fuel and compile the ByteArray in a method. >> 2. The most readable one will be using STON and compiling the STON string into a method >> >> Maybe I should try both. > I'd be very interested in what you find. I guess Fuel is smaller and maybe even faster. STON, OTOH, is much friendlier for comparing versions and such. > Well, the first test froze (hot freeze taking 100% CPU) my image. The model serialized to Fuel is > 280Kb and clicking anywhere in the image that might show the code of the compiled method just makes the image unresponsive. :) I'll report further findings, Norbert

July 23, 2013

Re: [Pharo-users] Storing test data in methods

by jtuchel＠objektfabrik.de

Norbert, Am 23.07.13 14:07, schrieb Norbert Hartl: > Joachim, > > I'm aware that you can do serialization/deserialization yourself. I was asking for something to help along the way because a have quite some model classes to cover. I want a more generalized way of doing it. As often I really think about things _after_ I've sent the mail :) We seem to have a lot in common here. Regard it this way: sending the mail made you think again. So the mail itself was all but useless. > I think I have to options: > > 1. The most generic one is serializing into Fuel and compile the ByteArray in a method. > 2. The most readable one will be using STON and compiling the STON string into a method > > Maybe I should try both. I'd be very interested in what you find. I guess Fuel is smaller and maybe even faster. STON, OTOH, is much friendlier for comparing versions and such. Joachim

July 23, 2013

Re: [Pharo-users] Storing test data in methods

by Norbert Hartl

Joachim, Am 23.07.2013 um 13:25 schrieb "jtuchel(a)objektfabrik.de" <jtuchel(a)objektfabrik.de>: > Norbert, > > for similar purposes (INI-File contents etc.), in order to keep them under version control in envy, I wrote methods that produced a String that could recreate the objects when evaluated. Such a piece of text makes for a great class or instance method that you can compile into some Smalltalk class and get it under version control together with the code that uses the objects. > > Example: IniFileEntry with iVars #key and #value > instance method: > > creationStringOn: aStream > aStream nextPutAll: self class name; nextPut: $=; nextPutAll: self value asString. > > Thus you can ask all your IniFileEntries to write their own creation string onto a Stream and compile that into a method. You can see me talking about this and other related stuff here: http://www.objektfabrik.de/Downloads/VASTForum2010/VFM10-04-GetBackToShapre… (chapter "Get Everything under Version control, ca. 1/3 through the recording) > I'm aware that you can do serialization/deserialization yourself. I was asking for something to help along the way because a have quite some model classes to cover. I want a more generalized way of doing it. As often I really think about things _after_ I've sent the mail :) I think I have to options: 1. The most generic one is serializing into Fuel and compile the ByteArray in a method. 2. The most readable one will be using STON and compiling the STON string into a method Maybe I should try both. thanks, Norbert > > m 23.07.13 12:47, schrieb Norbert Hartl: >> I try to untangle my modules. I have a parser that creates a model and a tool that uses that model. For testing it is convenient to just generate the model and work with it. But this way I introduce dependencies which always pulls everything in. >> >> In order to untangle I would need a way to easily serialize the runtime model into methods or something similar. Anything that can be transported via monticello is ok. I just don't want to have dependencies to present of external files. That would just change the problem but not solving it. >> >> Any ideas? >> >> Norbert >> > >

July 23, 2013

Re: [Pharo-users] Storing test data in methods

by Norbert Hartl

Am 23.07.2013 um 13:20 schrieb HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > Have a look at InstanceEncoder > > http://www.smalltalkhub.com/#!/~hernan/InstanceEncoder > Thanks, how would you say it works compared to store an Fuel ByteArray? Norbert > > El 23/07/2013 7:47, Norbert Hartl escribiÃ³: >> I try to untangle my modules. I have a parser that creates a model and a tool that uses that model. For testing it is convenient to just generate the model and work with it. But this way I introduce dependencies which always pulls everything in. >> >> In order to untangle I would need a way to easily serialize the runtime model into methods or something similar. Anything that can be transported via monticello is ok. I just don't want to have dependencies to present of external files. That would just change the problem but not solving it. >> >> Any ideas? >> >> Norbert >> > >

July 23, 2013

Re: [Pharo-users] Storing test data in methods

by jtuchel＠objektfabrik.de

HI again, I just saw the link I posted doesn't work right now. The objektfabrik site moved to a new server a while agow and it seems a few files didn't make it. The upload is currently in process, so please check back in an hour or so. Joachim Am 23.07.13 13:25, schrieb jtuchel(a)objektfabrik.de: > Norbert, > > for similar purposes (INI-File contents etc.), in order to keep them > under version control in envy, I wrote methods that produced a String > that could recreate the objects when evaluated. Such a piece of text > makes for a great class or instance method that you can compile into > some Smalltalk class and get it under version control together with > the code that uses the objects. > > Example: IniFileEntry with iVars #key and #value > instance method: > > creationStringOn: aStream > aStream nextPutAll: self class name; nextPut: $=; nextPutAll: self > value asString. > > Thus you can ask all your IniFileEntries to write their own creation > string onto a Stream and compile that into a method. You can see me > talking about this and other related stuff here: > http://www.objektfabrik.de/Downloads/VASTForum2010/VFM10-04-GetBackToShapre… > (chapter "Get Everything under Version control, ca. 1/3 through the > recording) > > HTH, > > Joachim > > > m 23.07.13 12:47, schrieb Norbert Hartl: >> I try to untangle my modules. I have a parser that creates a model >> and a tool that uses that model. For testing it is convenient to just >> generate the model and work with it. But this way I introduce >> dependencies which always pulls everything in. >> >> In order to untangle I would need a way to easily serialize the >> runtime model into methods or something similar. Anything that can be >> transported via monticello is ok. I just don't want to have >> dependencies to present of external files. That would just change the >> problem but not solving it. >> >> Any ideas? >> >> Norbert >> > > >

July 23, 2013

Re: [Pharo-users] Storing test data in methods

by jtuchel＠objektfabrik.de

Norbert, for similar purposes (INI-File contents etc.), in order to keep them under version control in envy, I wrote methods that produced a String that could recreate the objects when evaluated. Such a piece of text makes for a great class or instance method that you can compile into some Smalltalk class and get it under version control together with the code that uses the objects. Example: IniFileEntry with iVars #key and #value instance method: creationStringOn: aStream aStream nextPutAll: self class name; nextPut: $=; nextPutAll: self value asString. Thus you can ask all your IniFileEntries to write their own creation string onto a Stream and compile that into a method. You can see me talking about this and other related stuff here: http://www.objektfabrik.de/Downloads/VASTForum2010/VFM10-04-GetBackToShapre… (chapter "Get Everything under Version control, ca. 1/3 through the recording) HTH, Joachim m 23.07.13 12:47, schrieb Norbert Hartl: > I try to untangle my modules. I have a parser that creates a model and a tool that uses that model. For testing it is convenient to just generate the model and work with it. But this way I introduce dependencies which always pulls everything in. > > In order to untangle I would need a way to easily serialize the runtime model into methods or something similar. Anything that can be transported via monticello is ok. I just don't want to have dependencies to present of external files. That would just change the problem but not solving it. > > Any ideas? > > Norbert >

July 23, 2013

Re: [Pharo-users] Storing test data in methods

by HernÃ¡n Morales Durand

Have a look at InstanceEncoder http://www.smalltalkhub.com/#!/~hernan/InstanceEncoder HernÃ¡n El 23/07/2013 7:47, Norbert Hartl escribiÃ³: > I try to untangle my modules. I have a parser that creates a model and a tool that uses that model. For testing it is convenient to just generate the model and work with it. But this way I introduce dependencies which always pulls everything in. > > In order to untangle I would need a way to easily serialize the runtime model into methods or something similar. Anything that can be transported via monticello is ok. I just don't want to have dependencies to present of external files. That would just change the problem but not solving it. > > Any ideas? > > Norbert >

July 23, 2013

Storing test data in methods

by Norbert Hartl

I try to untangle my modules. I have a parser that creates a model and a tool that uses that model. For testing it is convenient to just generate the model and work with it. But this way I introduce dependencies which always pulls everything in. In order to untangle I would need a way to easily serialize the runtime model into methods or something similar. Anything that can be transported via monticello is ok. I just don't want to have dependencies to present of external files. That would just change the problem but not solving it. Any ideas? Norbert

July 23, 2013