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

Re: [Pharo-project] Planning a nice pharo conference :)

by Mariano Martinez Peck

I would like to go :) On Thu, Oct 13, 2011 at 10:21 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > Good idea! > We should include a research flash track where people can quickly show what > they are working on. > For the date, having it near ICSE'12 would be good. > > Alexandre > > > On 13 Oct 2011, at 17:12, StÃ©phane Ducasse wrote: > > > Hi guys > > > > the last time when we met with sven, we came up with the idea of doing a > nice pharo conference targeted at exchanging information, > > frameworks, tips and trick on server set up, community building, drinking > beers and more. > > > > So we could host such conference in beginning of may for example. What do > you think? > > Would you be interested to join a two-three days conference focusing on > dev and business? > > > > Stef > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- Mariano http://marianopeck.wordpress.com

Oct. 13, 2011

Re: [Pharo-project] Planning a nice pharo conference :)

by Alexandre Bergel

Good idea! We should include a research flash track where people can quickly show what they are working on. For the date, having it near ICSE'12 would be good. Alexandre On 13 Oct 2011, at 17:12, StÃ©phane Ducasse wrote: > Hi guys > > the last time when we met with sven, we came up with the idea of doing a nice pharo conference targeted at exchanging information, > frameworks, tips and trick on server set up, community building, drinking beers and more. > > So we could host such conference in beginning of may for example. What do you think? > Would you be interested to join a two-three days conference focusing on dev and business? > > Stef > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 13, 2011

[Pharo-project] Planning a nice pharo conference :)

by StÃ©phane Ducasse

Hi guys the last time when we met with sven, we came up with the idea of doing a nice pharo conference targeted at exchanging information, frameworks, tips and trick on server set up, community building, drinking beers and more. So we could host such conference in beginning of may for example. What do you think? Would you be interested to join a two-three days conference focusing on dev and business? Stef

Oct. 13, 2011

Re: [Pharo-project] [update 1.4] #14191

by StÃ©phane Ducasse

Oh yes! took us some times to get in but it is worth it. Stef > This is exciting :) > > Doru > > > On 12 Oct 2011, at 11:43, StÃ©phane Ducasse wrote: > >> The kind of update we all love :) >> >> Stef >> http://code.google.com/p/pharo/issues/detail?id=4904 >> 14191 >> ----- >> >> - Speed improvement: 10 to 12 times faster ! >> the speed is now very near from what is possible with PluggableListMorph. >> the TimeProfiler is now very efficient. >> >> - made MorphTreeModel composable (see MCSliceMaker which is not a MorphTreeModel subclass anymore) >> >> - Start to use Annoucements instead of change/update (see MorphTreeSelectionChanged announcement) >> >> - no item forgotten when sliding with the mouse for auto multiselection (as in the TestRunner, try to select items with the mouse, some items are not selected if the mouse slides too fast) >> >> - no need for TickList* (8 classes) and no need for a CheckList class > > -- > www.tudorgirba.com > > "Beauty is where we see it." > > > >

Oct. 13, 2011

Re: [Pharo-project] [update 1.4] #14191

by Tudor Girba

This is exciting :) Doru On 12 Oct 2011, at 11:43, StÃ©phane Ducasse wrote: > The kind of update we all love :) > > Stef > http://code.google.com/p/pharo/issues/detail?id=4904 > 14191 > ----- > > - Speed improvement: 10 to 12 times faster ! > the speed is now very near from what is possible with PluggableListMorph. > the TimeProfiler is now very efficient. > > - made MorphTreeModel composable (see MCSliceMaker which is not a MorphTreeModel subclass anymore) > > - Start to use Annoucements instead of change/update (see MorphTreeSelectionChanged announcement) > > - no item forgotten when sliding with the mouse for auto multiselection (as in the TestRunner, try to select items with the mouse, some items are not selected if the mouse slides too fast) > > - no need for TickList* (8 classes) and no need for a CheckList class -- www.tudorgirba.com "Beauty is where we see it."

Oct. 13, 2011

Re: [Pharo-project] P2P library in Smalltalk

by StÃ©phane Ducasse

Ok you will have to show me that again and that we remove some dust. Did you implement some distributed hash maps? Stef > StÃ©f, > > P2P is what my team did in the UbiquiTalk project (2005-2009) :-) > > -Pairs discover each other dynamically. No prior config/IP setup is required, but you need to be connected to the same network that allows multi-casting in > > -Each pair can provide 0 or more services available. A service is a piece of code. A service has 2 parts : one that runs on the provider (can be empty) and one that runs on the requestor. > > -Another pair can decide to use a service provided by another one => it downloads and installs the requestor part of the service and run it. Then it does what ever it is made for. > > The project is currently stalled. All the code is on SqueakSource though I believe it won't run out of the box on Pharo 1.2/1.3 (too many connections to morphic). The design needs many improvements and there are some bugs (including one problematic due to rST). Still, we made several demos with it including critical ones (with many CEOs and CTOs as an audience). We had UbiquiTalk running on PDA with pocket windows... > > Noury > -- > http://twitter.com/#!/NouryBouraqadi > > > On 13 oct. 2011, at 16:57, StÃ©phane Ducasse wrote: > >>> Hi guys >>>> >>>> is there a library for doing P2P in Smalltalk? >>>> >>> >>> Peer to Peer in which sense? >>> >>> Data transfer? >> >> Yes >> It would be fun to see if we could replicate all the mcz files we all have in our caches. >> >> >> >> > > > > > Noury > -- > http://twitter.com/#!/NouryBouraqadi > > > > > >

Oct. 13, 2011

Re: [Pharo-project] [squeak-dev] Any serializer can customize serialization strategy?

by Martin Dias

Hi Hernan, Could your "specific Strings" be instances of a variant of RemoteString that compresses and decompresses? Then they will occupy less memory in your image and it would be easier to serializer and deserialize the proxy object. Thanks for the feedback, I also don't like the visitor interface we have for customizations. In fact, I think it is not a visitor but a double-dispatch. And I would prefer to merge the two hooks Mariano proposed to something like: String >> fuelMapOn: aDefaultMapper (ExternalCompressor shouldCompressString: self) ifTrue: [aDefaultMapper mapSubstitution: self by: (ExternalCompressor compress: self)] ifFalse: [super fuelMapOn: aDefaultMapper] Do you like more this way? Martin On Tue, Oct 11, 2011 at 4:10 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Tue, Oct 11, 2011 at 12:56 AM, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> Thanks Mariano, >> >> That's pretty much what I want, but... why to expose the visitor >> interface? ;) >> > > Good question. Honesty, it was the only way we have found to do it with > Fuel. I think (but I am not sure) that one of the drawbacks of the pickle > format is that it analysis phase (as we call it in Fuel) make some hooks > more complicated to implement than a classic serializer. > > >> Just to give a little feedback of what I have in my mind: >> >> mySerializer setEngine: ExternalCompressor for: ( MyClass -> #myStringIVar >> ) >> >> > Well, you can also create an specific Fuel cluster for MyClass that does > exactly that. Basically you have to create FLMyClassCluster, implement > methods like #serializeWith: and #materializeFrom: and there you > serialize/materialize the specific #myStringIVar with a special way and the > rest as normal. Then you subclass the FLDefaultMapper, say YourMapper and > you implement #visitXXX > Then you have to implement MyClass >> visitXXX. > Of course, you should be able to generalize such cluster and be able to > reuse it for different classes or instVars. > > I am not saying this is the best way. I am just telling you one possible > solution you can do by extending Fuel for your needs. Of course, you may > need to understand how Fuel works first. But of course, we can help if you > want. > > >> or >> >> mySerializer setEngine: ExternalCompressor for: incomingStream >> >> Now with machines generating daily 6 TBytes of raw data, one of the >> keys will be data compression. >> > > > it looks like ;) > > > >> 2011/10/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> > >> > >> > On Mon, Oct 10, 2011 at 9:35 PM, HernÃ¡n Morales Durand >> > <hernan.morales(a)gmail.com> wrote: >> >> >> >> Is there any serializer (Fuel/StOMP/Ma object >> >> serialization/BOSS/SRP/SIXX??) which let me attach an external >> >> compressor/decompressor for specific Strings to the >> >> serialization/deserialization process? >> > >> > In Fuel you can do: >> > >> > String >> fuelSubstitution >> > ^ ExternalCompressor compress: self >> > >> > String >> fuelAccept: aVisitor >> > ^ (ExternalCompressor shouldCompressString: self) >> > ifTrue: [aVisitor visitSubstitution: self] >> > ifFalse: [super fuelAccept: aVisitor] >> > >> > But the problem is that if #compress: answers an instance of String, you >> > should be careful that if #shouldCompressString: asnwers true to the >> > compressed string, then you will end up in an infinitive loop. >> > >> > See: http://rmod.lille.inria.fr/web/pier/software/Fuel/Hooks and >> > FLHookedSubstitutionTest >> > >> > I think StOMP should support this as well: >> > http://stomp.smalltalk-users.jp/home/how-to-use-stomp/hook-methods >> > >> > The previous hook you let you replace the original String with its >> > compression during serialization. Which make sense because if you are >> going >> > to compress it is better to do it during serialization. >> > >> >> With external I mean it could >> >> be in a separate binary (I could arrange the binding though). >> > >> > I am not sure if I understood. >> > >> > >> > >> >> >> >> Thanks >> >> >> >> HernÃ¡n >> >> >> > >> > >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> > >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > >

Oct. 13, 2011

Re: [Pharo-project] P2P library in Smalltalk

by Noury Bouraqadi

StÃ©f, P2P is what my team did in the UbiquiTalk project (2005-2009) :-) -Pairs discover each other dynamically. No prior config/IP setup is required, but you need to be connected to the same network that allows multi-casting in -Each pair can provide 0 or more services available. A service is a piece of code. A service has 2 parts : one that runs on the provider (can be empty) and one that runs on the requestor. -Another pair can decide to use a service provided by another one => it downloads and installs the requestor part of the service and run it. Then it does what ever it is made for. The project is currently stalled. All the code is on SqueakSource though I believe it won't run out of the box on Pharo 1.2/1.3 (too many connections to morphic). The design needs many improvements and there are some bugs (including one problematic due to rST). Still, we made several demos with it including critical ones (with many CEOs and CTOs as an audience). We had UbiquiTalk running on PDA with pocket windows... Noury -- http://twitter.com/#!/NouryBouraqadi On 13 oct. 2011, at 16:57, StÃ©phane Ducasse wrote: >> Hi guys >>> >>> is there a library for doing P2P in Smalltalk? >>> >> >> Peer to Peer in which sense? >> >> Data transfer? > > Yes > It would be fun to see if we could replicate all the mcz files we all have in our caches. > > > > Noury -- http://twitter.com/#!/NouryBouraqadi

Oct. 13, 2011

Re: [Pharo-project] [ANN] Pharo Glorp port release

by Mariano Martinez Peck

On Thu, Oct 13, 2011 at 1:56 PM, jtuchel(a)objektfabrik.de < jtuchel(a)objektfabrik.de> wrote: > Hi, > > DBXTalk is good work! > I really love to see that stuff going forward! > > Thanks. > Before I spend a lot of time playing around: has anybody tried using > Pharo/GLORP/ODBC (Access or SQLSrv) on Windows? > Yes, but I have to admit that it's almost the most complicated scenario to configure. At least I know someone tried Pharo/Glorp/ODBC/SQL Server. I think you can just give it a try. Get the dll of OpenDBX (they are in our website), get a Pharo VM that has a working FFI, and give it a try. > Or Pharo/GLORP/SQLite on Windows? > Yes, this works almost out of the box. In fact, I can provide you a zip that contains Pharo VM + image + opendbx dll + sqlite dll. > Is there some place on the web where I can find info on how to set this up? > > http://dbxtalk.smallworks.com.ar/Compiling%20and%20installing%20OpenDBX http://dbxtalk.smallworks.com.ar/Compiling%20for%20different%20backends > In an open source context, this is probably a heretic question, and if I > could choose freely, Linux and PostgresQL would be my favorite. > Sure, that's pretty easy. OpenDBX and PostgreSQL are easy to make it work in Linux. > OTOH: The fact that each windows installation comes with an Access engine > and respective ODBC driver makes the combination very attractive for > starting something on a windows machine really fast. No installation of > anything but Pharo, no need for admin rights or anything. Just set up the > odbc driver and off you go! Great chance to show the strength of Smalltalk > and Glorp to other team members and friends... > well more or less. In the case of DBX you will need the OpenDBX library anyway, even if being ODBC. OpenDBX sees ODBC just as another backend. And of course, that's only if you like accessing by ODBC (which I don't like BTW). Of course, you can create a database driver for Glorp that uses the ODBC driver of squeak in which case you wouldn't need the OpenDBX driver. > SQLite is a similar story: copy the dlls onto the machine and the journey > can start. > > yes, that's even easier. As I say, it can be provided in a "DBXOneClick" :) Cheers -- Mariano http://marianopeck.wordpress.com

Oct. 13, 2011

Re: [Pharo-project] P2P library in Smalltalk

by StÃ©phane Ducasse

> Hi guys >> >> is there a library for doing P2P in Smalltalk? >> > > Peer to Peer in which sense? > > Data transfer? Yes It would be fun to see if we could replicate all the mcz files we all have in our caches.

Oct. 13, 2011