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

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

by Schwab,Wilhelm K

I'm not sure about the RAM, and the battery is dead at the moment. The screen is small, but I specifically wanted a handheld that was *not* a phone; it was a fairly big disappointment for software reasons. I would forget my head w/o my Palm 32, but the world is changing. As an aside, I might try an iPod touch; I just want a PDA. I would definitely plan to develop elsewhere and copy to it. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Dimitry Golubovsky [golubovsky(a)gmail.com] Sent: Friday, January 06, 2012 1:30 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] happy new year plus cogdroid news Schwab,Wilhelm K wrote: > Does an Archos 43 count as an Android device? I bought it with plans that fell flat (the target moved, and the OS was a little disappointing). That said, I have it and can > help with testing. I do not have a data plan for it, so my default usage is to copy packages to it via USB. I think it counts, but AFAIK is has 4.3" screen, correct - sized more like a phone? But technically you should be able to run CogDroid on it given enough RAM is available (someone I remember tried it on a phone with 128M RAM and that was not sufficient) 256M should be OK. If you have wifi on the tablet you should be able to hook it up with a home wifi router - only you need to have NAT enabled since Android browser does not use HTTP proxy. Pharo can be configured to use a proxy though so you can access Monticello repos also such way. > It is hard to imagine developing on it, but I'm willing to be pleasantly surprised, and it would be nice to be able to deploy Pharo apps on hand-held devices. You may develop on a PC and then transfer the image to the tablet. Or load packages from Monticello repos as usual (with proxy or NAT).

Jan. 6, 2012

Re: [Pharo-project] About ConfigurationOfXMLSupport

by StÃ©phane Ducasse

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

[Pharo-project] What should be in a configuration?

by Dale Henrichs

Obviously, this post is inspired by the 'About ConfigurationOfXMLSupport' thread[1] on the pharo list. Many of the issues with ConfigurationOfXMLSupport are mired in a history that goes back to the very beginnings of Metacello. In the end ConfigurationOfXMLSupport is what it is... When it comes to what should be in a configuration, my opinion is that each project on SqueakSource should have a configuration. If it is worth having a separate project on SqueakSource, then it is worth having a configuration. Yes, even if there is only one package in the project it should have a configuration. The reasoning is simple: - projects evolve over time - as projects grow, eventually it makes sense to split the project into multiple packages - as projects grow, they are ported to other platforms and not all ports can be done without writing some platform specific code that needs to be packaged in a separate package - as projects grow, they become dependent upon other projects ... - over time the support for a project on VERSIONS of a platform change. Support is dropped for one version and added for another - over time the project API changes and not everyone can immediately move to the new API - over long enough periods, projects move from one repository to another Configurations were invented to address these problems and some of these problems exist no matter how many packages or dependent projects are involved. If I use a configuration to load the code from a project, all I have to worry about is which version of the project I want to use. When I see a new version is available, I can control when I load that new code and be assured that the code won't move out from under me ... Remember the message from the Metacello presentation that Mariano and I gave at ESUG 2010[2]: Configurations are NOT for the DEVELOPERS of a project but for the USERS of a project Dale [1] http://forum.world.st/About-ConfigurationOfXMLSupport-td4244103.html [2] http://www.youtube.com/watch?v=zWHS5xIo_xI&feature=youtu.be&a

Jan. 6, 2012

[Pharo-project] happy new year plus cogdroid news

by Dimitry Golubovsky

Hi, I saw responses from several people, will answer to everybody in a single message. StÃ©phane Ducasse wrote: >> It would be nice if a smaller base Pharo image could be built such >> way, so it could be embedded with VM and distributed together. > yes we are working slowly but steadily on that. > Did you try the pavel image? Not yet, but you just reminded me that it exists; eventually I'll try it out ;) Alain Rastoul wrote: > And if yu have an APK that I can download somewhere else than on the market, I never put CogDroid on the market - it is in google code. > I am interested > (the ALT and CTL key missing are really painful, I use the blue/yellow > button emulation but it is not cool) Give me some time to finish locale support, and I'll put some apks to a temporary location (other than google code - downloads in google code are unremovable). Keyboard modifiers work fine in x86 Android, but I just don't have any ARM device with keyboard to test it. > I am not sure the image size is really a problem on a tablet ? > lot of games - angry birds game (free on android market ) for example- are > about 30MB if I m right, It is more about the fact that bundling an image together with apk makes the image immutable. Such approach would be good if a specific application is shipped, or to have a "starter" image that provides a more convenient framework to download/upgrade other images than just doing that in Android browser. > I clearly had the feeling that the battery is going down faster when I use > Pharo perhaps because not all Smalltalk processes are sleepng and so the vm > never sleep ? > The UI morphic process make pauses of 20 ms when there is not event , I > don't know for others processes (Timer event loop, Input events process). > I have to investigate Have a look at this file: http://gitorious.org/~golubovsky/cogvm/dmg-blessed/blobs/master/platforms/a… methods of interest are timerEvent, and every method that calls it. The timerEvent method spawns a thread which generates a predefined (or infinite) number of timer events with given interval (timerDelay which is hardcoded as 200ms). But when interpreter returned by interval timer (this is necessary to have Android runtime poll for events), it will be reentered immediately beause there is some unfinished business. If user input is received, additional timer threads will be spawned, for limited amount of events generated. I may set this timerDelay to much larger value. But then VM will be frozen until any user input arrives - even server mode flag won't help. Even cursors in text inputs will stop blinking. Maybe this timerDelay has to be configurable if battery life is a concern. > Cool, if the clipboard vm primitives are ok, the System Clipboard class > should work ?. Not yet. All I have is a primitive that reads from Android clipboard (maybe I need to add one that writes there), but it has not been integrated with the rest of the image (and such integration is not really part of the VM). Perhaps a pair of items has to be added to the text editing context menu to copy/cut to and paste from Android clipboard. Schwab,Wilhelm K wrote: > Does an Archos 43 count as an Android device? I bought it with plans that fell flat (the target moved, and the OS was a little disappointing). That said, I have it and can > help with testing. I do not have a data plan for it, so my default usage is to copy packages to it via USB. I think it counts, but AFAIK is has 4.3" screen, correct - sized more like a phone? But technically you should be able to run CogDroid on it given enough RAM is available (someone I remember tried it on a phone with 128M RAM and that was not sufficient) 256M should be OK. If you have wifi on the tablet you should be able to hook it up with a home wifi router - only you need to have NAT enabled since Android browser does not use HTTP proxy. Pharo can be configured to use a proxy though so you can access Monticello repos also such way. > It is hard to imagine developing on it, but I'm willing to be pleasantly surprised, and it would be nice to be able to deploy Pharo apps on hand-held devices. You may develop on a PC and then transfer the image to the tablet. Or load packages from Monticello repos as usual (with proxy or NAT). Ben Coman wrote: > Consider getting a Jenkins build going with an Android emulator. Sounds interesting if I could set up build jobs for CogDroid if there are Android build tools on Jenkins. Hopefully I haven't missed anythng - feel free to ask more questions ;) Thanks. -- Dimitry Golubovsky Anywhere on the Web

Jan. 6, 2012

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

by Alain Rastoul

Hi Guido, Sure, nobody will redevelop the google stack or APIs, just interface with it. The Pharo image have an event mechanism, and IMHO it should be possible to make some interface to Andoid APIs. If i'm correct the Nexus is a phone, not a tablet ? Alain "Guido Stepken" <gstepken(a)googlemail.com> a Ã©crit dans le message de news: CANXOX8-4-XPfvjChy8VR9Q_kO7MGeZ7rO4YzRAna28a6iZR3EA(a)mail.gmail.com... 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-rev… [2] https://wiki.jenkins-ci.org/display/JENKINS/Android+Emulator+Plugin [3] http://www.cyanogenmod.com/ [3a] http://www.cyanogenmod.com/devices [3b] https://www.eff.org/deeplinks/2011/12/carrier-iq-architecture [4] http://www.kickstarter.com/start [4a] http://www.kickstarter.com/help/faq/kickstarter%20basics#WhatIsKick [4b] http://www.kickstarter.com/projects/1541803748/punk-mathematics?play=1&ref=… [4c] http://www.kickstarter.com/projects/1992078142/building-the-open-source-bus… (sorry for the many links) cheers, Ben

Jan. 6, 2012

Re: [Pharo-project] Refactor class > Accessors not working for instvars with leading numeric

by Lukas Renggli

The Smalltalk syntax does not allow leading numbers in variable or selectors. Prefix it with an underscore. It is strange that you could add an instance-variable with that name in the first place. Lukas On 6 January 2012 16:34, Ben Coman <btc(a)openinworld.com> wrote: > For the following accepted class definition (so presumably leading zero is a > valid instance variable name), > from the menu selecting Â "Refactor class > Accessors" > fails with "Error: End of statement list encountered > > EpcimIdentifiedObject subclass: #EpcimBaseVoltage > Â instanceVariableNames: '0nVoltageLevel' > Â classVariableNames: '' > Â poolDictionaries: '' > Â category: 'IEC61970-Core' > > If I take away the leading zero on the instance variable it works okay. Â I > can get by with it not working but wondered whether I log a bug report or am > I doing something wrong? Â I do want to keep the leading zero because I am > using it to mark the multiplicity of associations (eg see > BaseVoltage/Voltage down the bottom of [1]). > [1] > http://forum.world.st/forward-engineering-UML-models-into-Smalltalk-code-td… > -- Lukas Renggli www.lukas-renggli.ch

Jan. 6, 2012

[Pharo-project] Refactor class > Accessors not working for instvars with leading numeric

by Ben Coman

For the following accepted class definition (so presumably leading zero is a valid instance variable name), from the menu selecting "Refactor class > Accessors" fails with "Error: End of statement list encountered EpcimIdentifiedObject subclass: #EpcimBaseVoltage instanceVariableNames: '0nVoltageLevel' classVariableNames: '' poolDictionaries: '' category: 'IEC61970-Core' If I take away the leading zero on the instance variable it works okay. I can get by with it not working but wondered whether I log a bug report or am I doing something wrong? I do want to keep the leading zero because I am using it to mark the multiplicity of associations (eg see BaseVoltage/Voltage down the bottom of [1]). [1] http://forum.world.st/forward-engineering-UML-models-into-Smalltalk-code-td…

Jan. 6, 2012

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

by Mariano Martinez Peck

> >>> Thanks Levente. However, #pointersToExcept: does a GC at the >> beginning... >> so.. am I missing something? >> > > Yes, at the beginning The MethodContexts are created after that GC. > > But those MC shouldn't be excluded by the instVar objectsToAlwaysExclude ? objectsToAlwaysExclude := { results collector. thisContext. thisContext sender. thisContext sender sender. objectsToExclude. }. > > Levente > > >> Thanks again. >> >> >> >>> Levente >>> >>> >>> >>> >>>> Do you mean what I understand :)? that some tools compiled methods? :) >>>> >>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.****com <http://marianopeck.wordpress.** >>>> com <http://marianopeck.wordpress.com>> >>>> >>>> >>> >> >> -- >> Mariano >> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >> > -- Mariano http://marianopeck.wordpress.com

Jan. 6, 2012

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

by Levente Uzonyi

On Fri, 6 Jan 2012, Mariano Martinez Peck wrote: > 2012/1/6 Levente Uzonyi <leves(a)elte.hu> > >> 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-why-it-**fixes-td4244097.html<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. > > > yes > > >> 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. > > > probably > > >> 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. >> >> > Thanks Levente. However, #pointersToExcept: does a GC at the beginning... > so.. am I missing something? Yes, at the beginning The MethodContexts are created after that GC. Levente > > Thanks again. > > >> >> Levente >> >> >> >>> >>> Do you mean what I understand :)? that some tools compiled methods? :) >>> >>>> >>>> Stef >>>> >>>> >>>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Jan. 6, 2012

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

by Mariano Martinez Peck

2012/1/6 Levente Uzonyi <leves(a)elte.hu> > 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-why-it-**fixes-td4244097.html<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. yes > 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. probably > 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. > > Thanks Levente. However, #pointersToExcept: does a GC at the beginning... so.. am I missing something? Thanks again. > > Levente > > > >> >> Do you mean what I understand :)? that some tools compiled methods? :) >> >>> >>> Stef >>> >>> >>> >> >> -- >> Mariano >> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >> > -- Mariano http://marianopeck.wordpress.com

Jan. 6, 2012