January 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Bug in #pointsTo: ?

by Levente Uzonyi

On Fri, 6 Jan 2012, Mariano Martinez Peck wrote: > On Fri, Jan 6, 2012 at 2:59 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr>wrote: > >> >> On Jan 6, 2012, at 2:46 PM, Levente Uzonyi wrote: >> >>> Of course, but I'd check for the class equality first, because it's >> faster (yeah, i know you turned off inlining of #class, but Cog doesn't >> care about that ;)). > > > Ok, makes sense. > > >> Another thing that you should add (besides tests of course) is >> SmallInteger >> #pointsTo: which should return false. > > > Ok. > > >> Also make sure that pointer tracing tools use #pointsTo:. In Squeak I >> found that some of them "reinvented" this method? >> >> > I found a problem with the PointerFinder: > http://forum.world.st/Help-pointersTo-broken-and-fix-but-I-don-t-understand… > However, I still don't understand why it works if I use #instVarsInclude: > and doesn't with #pointsTo: IIUC your problem is that MethodContext instances show up as objects which point to your object. And in fact (i think, but didn't check) they do point to your object, because the sender of those MethodContexts is the Date object. I think it only depends on when GC will happen. If the GC kicks in too late, then PointerFinder will find those transient objects and they will be listed. Levente > > > Do you mean what I understand :)? that some tools compiled methods? :) >> >> Stef >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Jan. 6, 2012

Re: [Pharo-project] happy new year plus cogdroid news

by Guido Stepken

Hi! With Android 4.0 the complete design has changed a lot. Icons have become scalable, have direct path to different service daemons, written in C++, Java, Linux increasingly becomes an "event machine" reacting on streams coming over BlueTooth, Wifi, Wimax, USBGPS, GSM, SMS, UMTS, HSPA+, LTE, informing apps, starting processes. A few thousand man-years have been invested by Google already, no chance *ever* for any team to keep up with. Android 4.0 is a free advertising platform on handy. I am using 4.0.x on Nexus for a few days now and am really surprised. I only get AD popups fullscreen from the OS (not within the browser) what i have been searching for on different platforms in the browser or having discussed via mail, twitter, facebook ... Google seems to collect information directly from my virtual keyboard (i have agreed to this explicitly, so please no paranoia!). Times have changed. You are no longer free to choose your programming language. Have fun, Guido Stepken Am 06.01.2012 06:40 schrieb "Ben Coman" <btc(a)openinworld.com>: > StÃ©phane Ducasse wrote: > >> Thanks dimity what you are doing is cool. >> Marcus we should buy an android device or get one: Olivier has one I >> think. >> >> >> > Smalltalk on Android is going to be fantastic - and possibly a killer app. > Which device will you get? In theory it wouldn't matter but in practice > it might. I have been considering getting an Android phone and my choice > may be influenced by yours. I might even consider donating some small $ > amount if the chosen phone aligns with my interests. Some random thoughts > (which ended up with a lot of links, so pick and choose your fancy)... > > Over christmas the "Samsung Galaxy S II" [1] appears to have been popular > with work colleagues here in Western Australia. > Consider getting a Jenkins build going with an Android emulator. [2] > > Consider basing first efforts on top of CyanogenMod [3] - which may be > attractive to early adopters to expand the compatibility base [3a] by > minimising to difference in manufacturer stack customisations. I > personally would use CyanogenMod in any case this to increase performance > by eliminating carrier installed bloatware and spyware like Carrier IQ [3b]. > > Have you seen the Kickstarter funding site [4] [4a] ? Some examples [4b] > [4c]. > [1] http://www.digitaltrends.com/**cell-phone-reviews/samsung-** > galaxy-s-ii-att-review/<http://www.digitaltrends.com/cell-phone-reviews/samsung-galaxy-s-ii-att-rev…> > [2] https://wiki.jenkins-ci.org/**display/JENKINS/Android+** > Emulator+Plugin<https://wiki.jenkins-ci.org/display/JENKINS/Android+Emulator+Plugin> > [3] http://www.cyanogenmod.com/ > [3a] http://www.cyanogenmod.com/**devices<http://www.cyanogenmod.com/devices> > [3b] https://www.eff.org/deeplinks/**2011/12/carrier-iq-**architecture<https://www.eff.org/deeplinks/2011/12/carrier-iq-architecture> > [4] http://www.kickstarter.com/**start <http://www.kickstarter.com/start> > [4a] http://www.kickstarter.com/**help/faq/kickstarter%20basics#** > WhatIsKick<http://www.kickstarter.com/help/faq/kickstarter%20basics#WhatIsKick> > [4b] http://www.kickstarter.com/**projects/1541803748/punk-** > mathematics?play=1&ref=search<http://www.kickstarter.com/projects/1541803748/punk-mathematics?play=1&ref=…> > [4c] http://www.kickstarter.com/**projects/1992078142/building-** > the-open-source-bussard-**fusion-reactor?ref=live<http://www.kickstarter.com/projects/1992078142/building-the-open-source-bus…> > > (sorry for the many links) > cheers, Ben > > >

Jan. 6, 2012

Re: [Pharo-project] About ConfigurationOfXMLSupport

by Norbert Hartl

Am 06.01.2012 um 15:04 schrieb StÃ©phane Ducasse: > > On Jan 6, 2012, at 2:36 PM, Norbert Hartl wrote: > >> >> Am 06.01.2012 um 14:13 schrieb StÃ©phane Ducasse: >> >>>> >>>> I disagree. There is more than one way to create a mess. One is what you describe! The other one you get by over-engineering things. If you create a configuration for every package that consist of one file only you will get tons of configuration files with hard to maintain dependencies. A bigger mess in my opinion (and experience). You always have to leverage the use and effect of doing things. Configurations can have groups which is an internal separation of things that belong together. >>>> As there are more ways to do it I have trouble understanding the "if each package move its clients...". There is no need to have a single approach. If it would be that way it would be good if pharo would just follow ANSI. >>> >>> So then why not having a single one? >> >> You don't need to prove you are stubborn sometimes. I know it :) > > good :) > >> >>> I do not use Sixx. >>> But I use XMLParser. >>> >>> So do you think that I can maintain pastel, sixx versions that I do not use? So do you think that having a large configuration >>> with parts that are unmaintained is good? >>> I do not think so. >>> >> Stef, what are you trying to tell? Of course, you can't maintain a software you do not use. Nobody tells me you maintain the software _that you_ use. But I can understand that you do not care about breaking clients of the software that you use and maintain. > > no but this is distribution of responsibilities. Only if there is one guy per ConfigurationOf and we know that is not the case. > This is like switch vs polymorphism. Switch are cool because all the logic is in one place but we know the price. Nice try! To me it appears to be more like having classes with only one method or make classes to do different things, e.g. have multiple methods. I can barely see something polymorphic in Configurations :) > Now if I want to have a jenkins system loading and running the tests of configurationOf then I prefer to have one per project. > Ah, you prefer?! Well, that's fine with me. >> And so it is better to have even the smallest client in its own configuration because if it would be in eye sight you might be forced to think about to care about this package as well. Is it like that? >> >>> So I will create a ConfigurationOfXMLParser. >>> >> Yes, and create it for pharo only, so I do not need to care about it. >>> >>>>>> Sixx is a serializer/deserializer for XML and therefor is using streams. Streams are one of those fine examples where platform differences can drive you nuts. I couldn't understand all the fuzz of not using sport and preferring grease for seaside but only for seaside etc. I had a hard time dealing with platform subtleties for character encoding (yes, I care!) and streams when it comes to dialects. So I decided to introduce grease and made the GemStone port of Sixx depend on streams and character encoding behaviour of grease (Please sue me!). Dale was so kind to make even GemStone Core to depend on Grease to make Xml loadable by the core. >>>>> >>>>> But put that in ConfigurationOfSixx :) >>>>> >>>> Well, just do it. >>> >>> I do not use Sixx. >>> But I use XMLParser. >>> >> If you load ConfigurationOfXMLSupport and use it _where_ do you see what is configured in there? > > If I use it then I have another configuration and I look at it to know what I need to load. For example I want to run XMLParser tests together > with my tests. > >> Maybe we should proceed this discussion in spring. I understand that in winter when the light is dim it is too easy to see the world in black and white. Not your fault! > > No we have sun here. > I have to read configurationOfXMLSupport because I have other packages that rely on it. > and the more complex it is the more painful for its clients. That is my point. I don't defend a mechanic where too much things are in one configuration. But we are talking about having _two_ things in there with the ability to refactor it when time has come. But ok, we are (ok, I do) hairsplitting already and while we both have fun, everybody else might find this discussion ridiculous already. Let's wait for the next chance to have some fun! Norbert

Jan. 6, 2012

Re: [Pharo-project] Bug in #pointsTo: ?

by Mariano Martinez Peck

On Fri, Jan 6, 2012 at 2:59 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > On Jan 6, 2012, at 2:46 PM, Levente Uzonyi wrote: > > > Of course, but I'd check for the class equality first, because it's > faster (yeah, i know you turned off inlining of #class, but Cog doesn't > care about that ;)). Ok, makes sense. > Another thing that you should add (besides tests of course) is > SmallInteger >> #pointsTo: which should return false. Ok. > Also make sure that pointer tracing tools use #pointsTo:. In Squeak I > found that some of them "reinvented" this methodâ¦ > > I found a problem with the PointerFinder: http://forum.world.st/Help-pointersTo-broken-and-fix-but-I-don-t-understand… However, I still don't understand why it works if I use #instVarsInclude: and doesn't with #pointsTo: Do you mean what I understand :)? that some tools compiled methods? :) > > Stef > > -- Mariano http://marianopeck.wordpress.com

Jan. 6, 2012

Re: [Pharo-project] Bug in #pointsTo: ?

by Levente Uzonyi

On Fri, 6 Jan 2012, StÃ©phane Ducasse wrote: > > On Jan 6, 2012, at 2:46 PM, Levente Uzonyi wrote: > >> Of course, but I'd check for the class equality first, because it's faster (yeah, i know you turned off inlining of #class, but Cog doesn't care about that ;)). Another thing that you should add (besides tests of course) is SmallInteger >> #pointsTo: which should return false. Also make sure that pointer tracing tools use #pointsTo:. In Squeak I found that some of them "reinvented" this method? > > Do you mean what I understand :)? that some tools compiled methods? :) No, they implemented more or less the same thing what #pointsTo: does (or should do). Levente > > Stef > > >

Jan. 6, 2012

Re: [Pharo-project] About ConfigurationOfXMLSupport

by Guillermo Polito

Stef, Maybe a good distribution is to have one configuration per project and then configuration of xml support only gathers those projects as a facade... We are doing that in dbxtalk :P On Fri, Jan 6, 2012 at 11:04 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Jan 6, 2012, at 2:36 PM, Norbert Hartl wrote: > > > > > Am 06.01.2012 um 14:13 schrieb StÃ©phane Ducasse: > > > >>> > >>> I disagree. There is more than one way to create a mess. One is what > you describe! The other one you get by over-engineering things. If you > create a configuration for every package that consist of one file only you > will get tons of configuration files with hard to maintain dependencies. A > bigger mess in my opinion (and experience). You always have to leverage the > use and effect of doing things. Configurations can have groups which is an > internal separation of things that belong together. > >>> As there are more ways to do it I have trouble understanding the "if > each package move its clients...". There is no need to have a single > approach. If it would be that way it would be good if pharo would just > follow ANSI. > >> > >> So then why not having a single one? > > > > You don't need to prove you are stubborn sometimes. I know it :) > > good :) > > > > >> I do not use Sixx. > >> But I use XMLParser. > >> > >> So do you think that I can maintain pastel, sixx versions that I do not > use? So do you think that having a large configuration > >> with parts that are unmaintained is good? > >> I do not think so. > >> > > Stef, what are you trying to tell? Of course, you can't maintain a > software you do not use. Nobody tells me you maintain the software _that > you_ use. But I can understand that you do not care about breaking clients > of the software that you use and maintain. > > no but this is distribution of responsibilities. > This is like switch vs polymorphism. Switch are cool because all the logic > is in one place but we know the price. > > Now if I want to have a jenkins system loading and running the tests of > configurationOf then I prefer to have one per project. > > > And so it is better to have even the smallest client in its own > configuration because if it would be in eye sight you might be forced to > think about to care about this package as well. Is it like that? > > > >> So I will create a ConfigurationOfXMLParser. > >> > > Yes, and create it for pharo only, so I do not need to care about it. > >> > >>>>> Sixx is a serializer/deserializer for XML and therefor is using > streams. Streams are one of those fine examples where platform differences > can drive you nuts. I couldn't understand all the fuzz of not using sport > and preferring grease for seaside but only for seaside etc. I had a hard > time dealing with platform subtleties for character encoding (yes, I care!) > and streams when it comes to dialects. So I decided to introduce grease and > made the GemStone port of Sixx depend on streams and character encoding > behaviour of grease (Please sue me!). Dale was so kind to make even > GemStone Core to depend on Grease to make Xml loadable by the core. > >>>> > >>>> But put that in ConfigurationOfSixx :) > >>>> > >>> Well, just do it. > >> > >> I do not use Sixx. > >> But I use XMLParser. > >> > > If you load ConfigurationOfXMLSupport and use it _where_ do you see what > is configured in there? > > If I use it then I have another configuration and I look at it to know > what I need to load. For example I want to run XMLParser tests together > with my tests. > > > Maybe we should proceed this discussion in spring. I understand that in > winter when the light is dim it is too easy to see the world in black and > white. Not your fault! > > No we have sun here. > I have to read configurationOfXMLSupport because I have other packages > that rely on it. > and the more complex it is the more painful for its clients. > > > >

Jan. 6, 2012

Re: [Pharo-project] About ConfigurationOfXMLSupport

by StÃ©phane Ducasse

On Jan 6, 2012, at 2:36 PM, Norbert Hartl wrote: > > Am 06.01.2012 um 14:13 schrieb StÃ©phane Ducasse: > >>> >>> I disagree. There is more than one way to create a mess. One is what you describe! The other one you get by over-engineering things. If you create a configuration for every package that consist of one file only you will get tons of configuration files with hard to maintain dependencies. A bigger mess in my opinion (and experience). You always have to leverage the use and effect of doing things. Configurations can have groups which is an internal separation of things that belong together. >>> As there are more ways to do it I have trouble understanding the "if each package move its clients...". There is no need to have a single approach. If it would be that way it would be good if pharo would just follow ANSI. >> >> So then why not having a single one? > > You don't need to prove you are stubborn sometimes. I know it :) good :) > >> I do not use Sixx. >> But I use XMLParser. >> >> So do you think that I can maintain pastel, sixx versions that I do not use? So do you think that having a large configuration >> with parts that are unmaintained is good? >> I do not think so. >> > Stef, what are you trying to tell? Of course, you can't maintain a software you do not use. Nobody tells me you maintain the software _that you_ use. But I can understand that you do not care about breaking clients of the software that you use and maintain. no but this is distribution of responsibilities. This is like switch vs polymorphism. Switch are cool because all the logic is in one place but we know the price. Now if I want to have a jenkins system loading and running the tests of configurationOf then I prefer to have one per project. > And so it is better to have even the smallest client in its own configuration because if it would be in eye sight you might be forced to think about to care about this package as well. Is it like that? > >> So I will create a ConfigurationOfXMLParser. >> > Yes, and create it for pharo only, so I do not need to care about it. >> >>>>> Sixx is a serializer/deserializer for XML and therefor is using streams. Streams are one of those fine examples where platform differences can drive you nuts. I couldn't understand all the fuzz of not using sport and preferring grease for seaside but only for seaside etc. I had a hard time dealing with platform subtleties for character encoding (yes, I care!) and streams when it comes to dialects. So I decided to introduce grease and made the GemStone port of Sixx depend on streams and character encoding behaviour of grease (Please sue me!). Dale was so kind to make even GemStone Core to depend on Grease to make Xml loadable by the core. >>>> >>>> But put that in ConfigurationOfSixx :) >>>> >>> Well, just do it. >> >> I do not use Sixx. >> But I use XMLParser. >> > If you load ConfigurationOfXMLSupport and use it _where_ do you see what is configured in there? If I use it then I have another configuration and I look at it to know what I need to load. For example I want to run XMLParser tests together with my tests. > Maybe we should proceed this discussion in spring. I understand that in winter when the light is dim it is too easy to see the world in black and white. Not your fault! No we have sun here. I have to read configurationOfXMLSupport because I have other packages that rely on it. and the more complex it is the more painful for its clients.

Jan. 6, 2012

Re: [Pharo-project] Bug in #pointsTo: ?

by StÃ©phane Ducasse

On Jan 6, 2012, at 2:46 PM, Levente Uzonyi wrote: > Of course, but I'd check for the class equality first, because it's faster (yeah, i know you turned off inlining of #class, but Cog doesn't care about that ;)). Another thing that you should add (besides tests of course) is SmallInteger >> #pointsTo: which should return false. Also make sure that pointer tracing tools use #pointsTo:. In Squeak I found that some of them "reinvented" this methodâ¦ Do you mean what I understand :)? that some tools compiled methods? :) Stef

Jan. 6, 2012

Re: [Pharo-project] Bug in #pointsTo: ?

by Levente Uzonyi

On Fri, 6 Jan 2012, Mariano Martinez Peck wrote: > Hi guys. Levente recommended us to integrate the new version of #pointsTo:, > and I did it. But not I think I found a bug. The method is: > > pointsTo: anObject > "Answers true if I hold a reference to anObject, or false otherwise. Or > stated another way: > > Answers true if the garbage collector would fail to collect anObject > because I hold a reference to it, or false otherwise" > > ^ (self instVarsInclude: anObject) > or: [self class == anObject] > > > The problem is that if the receiver is an instance of a compact class, this > method answers true to: > 'aaa' pointsTo: ByteString > and I think that's incorrect. Moreoever, you can read the comment of the > method "Or stated another way: Answers true if the garbage collector would > fail to collect anObject because I hold a reference to it, or false > otherwise" > That's not true for compact classes. > > With this change: > > pointsTo: anObject > "Answers true if I hold a reference to anObject, or false otherwise. Or > stated another way: > > Answers true if the garbage collector would fail to collect anObject > because I hold a reference to it, or false otherwise" > > ^ (self instVarsInclude: anObject) > or: [(self class indexIfCompact = 0) and: [self class == anObject] ] > > it works fine. > > Do you agree with the change? Of course, but I'd check for the class equality first, because it's faster (yeah, i know you turned off inlining of #class, but Cog doesn't care about that ;)). Another thing that you should add (besides tests of course) is SmallInteger >> #pointsTo: which should return false. Also make sure that pointer tracing tools use #pointsTo:. In Squeak I found that some of them "reinvented" this method... Levente > > cheers > > -- > Mariano > http://marianopeck.wordpress.com >

Jan. 6, 2012

Re: [Pharo-project] About ConfigurationOfXMLSupport

by Norbert Hartl

Am 06.01.2012 um 14:13 schrieb StÃ©phane Ducasse: >> >> I disagree. There is more than one way to create a mess. One is what you describe! The other one you get by over-engineering things. If you create a configuration for every package that consist of one file only you will get tons of configuration files with hard to maintain dependencies. A bigger mess in my opinion (and experience). You always have to leverage the use and effect of doing things. Configurations can have groups which is an internal separation of things that belong together. >> As there are more ways to do it I have trouble understanding the "if each package move its clients...". There is no need to have a single approach. If it would be that way it would be good if pharo would just follow ANSI. > > So then why not having a single one? You don't need to prove you are stubborn sometimes. I know it :) > I do not use Sixx. > But I use XMLParser. > > So do you think that I can maintain pastel, sixx versions that I do not use? So do you think that having a large configuration > with parts that are unmaintained is good? > I do not think so. > Stef, what are you trying to tell? Of course, you can't maintain a software you do not use. Nobody tells me you maintain the software _that you_ use. But I can understand that you do not care about breaking clients of the software that you use and maintain. And so it is better to have even the smallest client in its own configuration because if it would be in eye sight you might be forced to think about to care about this package as well. Is it like that? > So I will create a ConfigurationOfXMLParser. > Yes, and create it for pharo only, so I do not need to care about it. > >>>> Sixx is a serializer/deserializer for XML and therefor is using streams. Streams are one of those fine examples where platform differences can drive you nuts. I couldn't understand all the fuzz of not using sport and preferring grease for seaside but only for seaside etc. I had a hard time dealing with platform subtleties for character encoding (yes, I care!) and streams when it comes to dialects. So I decided to introduce grease and made the GemStone port of Sixx depend on streams and character encoding behaviour of grease (Please sue me!). Dale was so kind to make even GemStone Core to depend on Grease to make Xml loadable by the core. >>> >>> But put that in ConfigurationOfSixx :) >>> >> Well, just do it. > > I do not use Sixx. > But I use XMLParser. > Believe me, nobody forces you to. > >> I personally would put xml parser, sixx, pastell, other xpath libs and the pull parser in a single configuration file. If someone likes to do XML stuff he/she will be fine to find it maintained in a single place. All of the mentioned libs are single packaged, tiny things. This would probably also help to find an existing lib before implemented your own (search for xpath in the mailing lists). >> I understand you are looking for something "clean". Well, knock yourself off. I'm more after usable units. > > No I'm looking for usable things too and when I load configurationOfXML to get the parser I'm not interested in the clients > of XMLParser, else you should also put Soup and a couple of others. > If you load ConfigurationOfXMLSupport and use it _where_ do you see what is configured in there? Maybe we should proceed this discussion in spring. I understand that in winter when the light is dim it is too easy to see the world in black and white. Not your fault! Norbert > >> >> Norbert >> >>> >>> >>>> Later I recognized that in pharo terms this is not possible. I had a discussion with Sven because I wanted to have a zinc port for gemstone. But he was more interested to get zinc close to pharo. So the grease way was not an option and the result is the port to gemstone is still incomplete and hard to maintain. >>>> >>>> Sorry for the long answer but this is just another story of how hard it is to have modular systems where all of the mentioned issues wouldn't be that much of a problem. I would wish that we find a good solution to make sources more interchangable between platforms. I don't mean get rid of the dialect differences (because I don't think it will happen) but to design code in a way that platform subtleties can be compensated in an object oriented way. >>>> >>>> Norbert >>>> >>>> >>> >>> >> >> > >

Jan. 6, 2012