May 2011 - Esug-list - lists.esug.org

Re: [Esug-list] ESUG SummerTalk - Fuel, binary object serializer

by Mariano Martinez Peck

On Mon, May 30, 2011 at 8:27 AM, Paolo Bonzini <bonzini(a)gnu.org> wrote: > On 05/29/2011 08:51 PM, Mariano Martinez Peck wrote: > >> But if I compare the serializing >> time and deserializing time of my thing, writing is about twice slower >> than reading. >> >> >> Yes, I think that is the normal and more or less the expected difference >> right now. >> >> > Do you want to make some comparisons with the GNU Smalltalk ObjectDumper? > I can help, or I can even make some comparisons myself if you give me some > test Fuel code and an image to test with. > > Hi Paolo. ObjectDumper was one of the serializers that we wanted to analyze also to get ideas and compare. This is why once I tried to install GNU Smalltalk in my machine but I couldn't so I give up. The problem to compare ObjectDumper is that we need to be able to run both in the same Dialect/VM. Otherwise the difference of the dialect or VM can change the results a lot. Sorry for the offtopic but is there an easy way to install GNU Smalltalk in a Mac OS 10.6.7 ? Thanks -- Mariano http://marianopeck.wordpress.com

May 30, 2011

Don't forget: Your talks at ESUG

by stephane ducasse

19th International Smalltalk Joint Conference - Call for Contributions Edinburgh, England August 20-26 2011; Camp Smalltalk September 20-21 http://esug.org/Conferences/2011/ This call includes: Developer program Free ESUG tickets International Workshop http://esug.org/Conferences/2011/International-Workshop-on-Smalltalk-Techno… Student Volunteer http://esug.org/Conferences/2011/Student+Volunteers+program Camp Smalltalk: Saturday 20th - Sunday 21st August 2011. ESUG conference: Monday 22nd - Friday 26th August 2011. This year will be held the - 7th edition of the Innovation Technology Awards where prizes will be awarded to authors of best pieces of Smalltalk-related projects - an international workshop on Smalltalk and dynamic languages http://www.esug.org/wiki/pier/Conferences/2011/International-Workshop-on-Sm… - ESUG will offer 10 free entrance tickets. To get a free ticket you should send a mail to the esug board (board(a)esug.org) Subject: [ESUG 2011 Free entrance] + your name And you should write a small motivation. You can support the ESUG conference in many different ways: * Sponsor the conference. New sponsoring packages are described at http://www.esug.org/supportesug/becomeasponsor/ * Submit a talk, a software or a paper to one of the events. See below. * Attend the conference. We'd like to beat the previous record of attendance (156 participants at Brest and 170 people at Amsterdam, 150 at Barcelona)! * Students can get free registration and hosting if they enroll into the the Student Volunteers program. See below. Developers Forum: International Smalltalk Developers Conference ------------------------------------------------------------------------ This year we are looking for YOUR experience on using Smalltalk. In addition, we are looking for tutorials. The list of topics includes, but is not limited to the following: * XP practices * Development tools * Experience reports * Model driven development * Web development * Team management * Meta-Modeling * Security * New libraries & frameworks * Educational material * Embedded systems and robotics * SOA and Web services * Interaction with other programming languages Submissions due on 1 July 2010 Notification of acceptance on 5 of July 2010 More information at http://www.esug.org/conferences/2011 How to submit? ------------------ Pay attention: the places are limited so do not wait till the last minute to apply. Prospective presenters should submit a request to board(a)esug.org AND stephane.ducasse(a)free.fr following the template below. Please use this template since the emails will be automatically processed! Subject: [ESUG 2011 Developers] + your name First Name: Last Name: Email where you can always be reached: Title: Abstract: Bio: Any presentation not respecting this form will be discarded automatically Innovation Technology Award ------------------------------------------------------------------------ We are proud to announce the 6th Innovation Technology Awards. The top 3 teams with the most innovative software will receive, respectively, 500 Euros, 300 Euros and 200 Euros during an awards ceremony at the conference. Developers of any Smalltalk-based software are welcome to compete. This year we will request 3-5min videos. More information at http://www.esug.org/Conferences/2011/Innovation+Technology+Awards Student Volunteer Program ------------------------------------------------------------------------ If you are a student wanting to attend ESUG, have you considered being a student volunteer? Student volunteers help keep the conference running smoothly; in return, they have free accommodations, while still having most of the time to enjoy the conference. More information at http://www.esug.org/conferences/2011 http://www.esug.org/Conferences/2011/Student+Volunteers+program We hope to see you there and have fun together. Ze ESUG board_______________________________________________

May 30, 2011

Re: [Esug-list] ESUG SummerTalk - Fuel, binary object serializer

by Paolo Bonzini

On 05/29/2011 08:51 PM, Mariano Martinez Peck wrote: > But if I compare the serializing > time and deserializing time of my thing, writing is about twice slower > than reading. > > > Yes, I think that is the normal and more or less the expected difference > right now. > Do you want to make some comparisons with the GNU Smalltalk ObjectDumper? I can help, or I can even make some comparisons myself if you give me some test Fuel code and an image to test with. Paolo

May 30, 2011

Re: [Esug-list] ESUG SummerTalk - Fuel, binary object serializer

by Yoshiki Ohshima

At Sun, 29 May 2011 20:52:45 +0200, Mariano Martinez Peck wrote: > > On Sun, May 29, 2011 at 8:45 PM, Yoshiki Ohshima <yoshiki(a)vpri.org> wrote: > > At Sat, 28 May 2011 09:33:27 +0200, > Stéphane Ducasse wrote: > > > > Yoshiki > > > > if you want to help testing, improving fuel you are welcome. > > The idea is to make it fast fast fast without vm support. > > Yeah. The reason for example I went to pad data to 4 bytes > > What do you mean by padding data to 4 bytes? I don't understand :( Say a string has length of 5 ('abcde'), the data in file for it would be "97 98 99 100 101 0 0 0". > was that > there may be a clever trick I may be able to do to read data into > arrays "directly" and stuff, > > what do you mean by that? like ImageSegment does? I mean, include also object headers in the stream and then avoid to recreate objects (using #basicNew) ? Not like ImageSegment, but more like #hackBits: reading from file into a string object of right size. For pointer arrays and actual literal fields, I am not sure I can apply this however. I would not put object headers, as you would agree^^; -- Yoshiki

May 29, 2011

Re: [Esug-list] ESUG SummerTalk - Fuel, binary object serializer

by Yoshiki Ohshima

At Sun, 29 May 2011 20:51:07 +0200, Mariano Martinez Peck wrote: > > But if I compare the serializing > time and deserializing time of my thing, writing is about twice slower > than reading. > > Yes, I think that is the normal and more or less the expected difference right now. Yes, more or less. It, however, seems that if I don't use OMeta2, it can be quite a lot faster. -- Yoshiki

May 29, 2011

Re: [Esug-list] ESUG SummerTalk - Fuel, binary object serializer

by Mariano Martinez Peck

On Sun, May 29, 2011 at 8:45 PM, Yoshiki Ohshima <yoshiki(a)vpri.org> wrote: > At Sat, 28 May 2011 09:33:27 +0200, > Stéphane Ducasse wrote: > > > > Yoshiki > > > > if you want to help testing, improving fuel you are welcome. > > The idea is to make it fast fast fast without vm support. > > Yeah. The reason for example I went to pad data to 4 bytes What do you mean by padding data to 4 bytes? I don't understand :( > was that > there may be a clever trick I may be able to do to read data into > arrays "directly" and stuff, what do you mean by that? like ImageSegment does? I mean, include also object headers in the stream and then avoid to recreate objects (using #basicNew) ? > but did not get around implementing it. > Next time I can try things, I'll give more close attention to Fuel... > > thanks :) > -- Yoshiki > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > -- Mariano http://marianopeck.wordpress.com

May 29, 2011

Re: [Esug-list] ESUG SummerTalk - Fuel, binary object serializer

by Mariano Martinez Peck

On Sun, May 29, 2011 at 8:48 PM, Yoshiki Ohshima <yoshiki(a)vpri.org> wrote: > At Sat, 28 May 2011 19:26:03 +0200, > Mariano Martinez Peck wrote: > > > > Thanks Yoshiki. So you said Fuel was 2x faster at reading...did you check > in writing (serializing) ? > > we would like to know the difference if possible. > > Well, the serializing part is definitely not tuned for performance. > It is even written in OMeta2! It does not support all bells and > whisles with new kinds of literals and stuff so I cannot really do a > meaningful comparison with Fuel. I understand. > But if I compare the serializing > time and deserializing time of my thing, writing is about twice slower > than reading. > > Yes, I think that is the normal and more or less the expected difference right now. -- Mariano http://marianopeck.wordpress.com

May 29, 2011

Re: [Esug-list] ESUG SummerTalk - Fuel, binary object serializer

by Yoshiki Ohshima

At Sat, 28 May 2011 19:26:03 +0200, Mariano Martinez Peck wrote: > > Thanks Yoshiki. So you said Fuel was 2x faster at reading...did you check in writing (serializing) ? > we would like to know the difference if possible. Well, the serializing part is definitely not tuned for performance. It is even written in OMeta2! It does not support all bells and whisles with new kinds of literals and stuff so I cannot really do a meaningful comparison with Fuel. But if I compare the serializing time and deserializing time of my thing, writing is about twice slower than reading. -- Yoshiki

May 29, 2011

Re: [Esug-list] ESUG SummerTalk - Fuel, binary object serializer

by Yoshiki Ohshima

At Sat, 28 May 2011 09:33:27 +0200, Stéphane Ducasse wrote: > > Yoshiki > > if you want to help testing, improving fuel you are welcome. > The idea is to make it fast fast fast without vm support. Yeah. The reason for example I went to pad data to 4 bytes was that there may be a clever trick I may be able to do to read data into arrays "directly" and stuff, but did not get around implementing it. Next time I can try things, I'll give more close attention to Fuel... -- Yoshiki

May 29, 2011

Re: [Esug-list] Fwd: Re: Proposal for Mock Objects at ESUG 2011

by Tim Mackinnon

This has been an interesting thread - and it definitely seems that there is enough interested to warrant a further talk on the subject. I encourage Frank to pursue his idea to submit a talk (sadly I can't attend ESUG this year - which I am disappointed about. However maybe Frank and I can confer offline, and I can share some ideas) As Neil pointed out (and more for background info) - I did present the ideas behind Mocks (and the library SMock, that was written for Dolphin) - back in 2007. I also did an update at Smalltalks 2009 and used the following screencast - http://www.planningcards.com/Thoughts/SMock%20and%20TDD%20in%20action.htm. I have to confess that I keep promising to fully port SMock to Pharo/Squeak - and have done most of the work but I got a bit stuck with Monticello and how to properly do extension methods as well as getting diverted onto other things. It also felt that people weren't very interested in the technique so I was writing something more for myself and for researching how it would impact my Smalltalk coding experience. (By the way there is now much more documentation on how to use Monticello, and Pharo is so much better, and with our renewed energy in the UKSmalltalk meetings I'm more inspired to seek some help to get something checked in). It sounds like Frank also has another interesting library that we should compare (and since then I have augmented another internal Mock library on a JPMorgan project which approaches things in a slightly different manner). While SteveF mentioned that we can implement testing strategies in quite a small amount of Smalltalk code - the bulk of code actually comes in making test failures communicate clearly and explicitly as well as giving you a nice level of expression that keeps tests readable (I think these latter points are very important for long lasting, useful tests). Having said all of this - many of these conversations do indicated a slight misunderstanding of Mocks and where they came from. To fill in a bit of background: When I helped invent the approach it was very much driven from wanting to do TDD - and although it was originally written in Java it was inspired from my experience in Smalltalk. I am particularly fond of CRC cards - and the approach of "role-playing" objects and interactions (yet another Smalltalk invention). In our experiments with TDD in 1999, I found that our Java testing seemed "dumbed down - and we were often tempted to add "getter" methods to just test something. It seemed a far cry from Smalltalk and CRC - until we focused back on how to express that role play in our test code by not adding getter methods. Thus if you did take the time to CRC - and looked at who you collaborated with - then expressing that in a test became more interesting. "I am supposed to collaborate with the PayrollCalculator - and if its the end of the month then I should ask it to #calculatePensionFor: employee on: date for every employee in my dataset. If I get the wrong date, or don't ask about every employee then I should fail the test." We found that if you could focus on encoding the CRC session in your tests, that you got better tests and better code, as well as better test failures. In Java it felt like you got code that was more Smalltalk like. So I guess I would comment that for us, Mocks were different because we wanted to focus testing on asserting relationships and interactions and less on data values. I read all the literature at the time (there is a massive book on Testing on my bookshelf from that time) - and nothing else seemed to have this same focus (stubs felt more data related). As we played with this more and more, we refactored out useful techniques to ease the assertion of relationships, and someone coined the term "Needs driven development". That is, the act of thinking in this way made you want to have relationships that you could assert against. For me - these were the "interesting tests" that we had been writing back in Connextra that felt better than the others. I think this also came out of our experiences of using TDD - and the observation that when you write tests for objects that you consider low hanging fruit (because you know you need them, and they seem easy to test) - invariably you make the wrong decision and test that something threw an exception instead of returning a boolean (or better still in Smalltalk, has an ifAbsent: style construct). Of course you only find out about this when you go to plug your well tested object into the place where you need it and discover that if you had just returned true/false then it would be much easier to use. So you go back, rejig the tests and you get a bit further until you discover another slightly wonky decision. After doing this a few times I made a point of saying to my team mates, lets always start with the top most object and write tests that help us learn what these smaller pieces (which we know we need) should actually do. This resonated well with CRC and really brought everything together for us. This is how MockObjects were born (and I asked Steve and Nat if they would like a chapter in their GOOS book about this history - and they happily included it as an afterward at the back). So coming back to Smalltalk - I still would argue that this CRC technique is very much alive, and I personally still find that "Needs Driven Development" is a useful technique. However it does mean that you get into a chicken and egg situation. If you start testing with a high level object - how do you test or get something working when you are referring to things that don't yet exist? For me, thats where Mocks step in - they are intended to be light weight proxies for things that don't yet exist. You do a CRC session, pick out the highest level object you can - code it (with tests) and mock out the relationships that you recorded on your CRC cards. As you are coding it, you will probably change your mind (writing real code has a way of doing that) - and you modify your lightweight relationship assertions (mocks). This also works best and is easier if you delegate responsibility and avoid returning complicated things (its easier to Mock and happily conforms to the law of Demeter). When you are happy enough with your top level object - you can then pick on one of those other relationships, and your tests should now show you the "Protocol" that this new object should have. So you create it - and repeat the process. The interesting twist that the screencast I linked to demonstrates - is that in Smalltalk (and indeed in Ruby or Python) we can create MockObjects that don't have any code, however you can use all those assertions to actually generate an object ready for you to test it. I think this is an interesting idea that needs more research (I feel that the right assertions could generate interesting code). As a final observation - when people talk about TestDoubles and MethodWrappers, I think they are missing the point of mocks as I intended them - as you can't double or wrap something that isn't yet written? So I would say that these techniques are perhaps better suited to code that is already in existence. Of course once you have done TDD with Mocks, and written your code you are then in a place where you can decide what to do? For me - I have kept the mocks in place - however I think in Smalltalk there is possibly a useful "Lint" check that makes sure your mock stays in sync with the underlying code (I haven't written any Slime style rules - but I think it would be interesting). There is also a useful hybrid functionality where you only mock certain methods and pass control to a real object underneath - or "method wrap" and decorate assertions you want on existing methods and pass down to the functionality underneath. I would argue that these are possibly more "maintenance" or "integration" style endeavours - and it would be a shame to not use the purer "Needs driven development" style when you can. Anyway - I hope this is a useful background and might inspire more work in the area. Tim

May 29, 2011