- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] Headless support for Cog Cocoa VM

by Igor Stasenko

On 23 January 2013 15:32, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > we have it > > is just you who cannot :) yeah.. but i would be much more happier to have stable VM compiled by LLVM compiler, because Apple abandoned GCC ;( -- Best regards, Igor Stasenko.

Jan. 23, 2013

Re: [Pharo-project] Athens replacement for ImageReadWriter?

by Denis Kudriashov

2013/1/23 Igor Stasenko <siguctua(a)gmail.com> > On 23 January 2013 14:56, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2013/1/23 Igor Stasenko <siguctua(a)gmail.com> > >> > >> On 23 January 2013 12:58, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> > Hi Fernando, > >> > > >> > I don't want a Form... quitte the opposite! :) > >> > What I want is to have something equivalent to athens to what now is > >> > covered > >> > in morphic with ImageReadWriter. > >> > > >> > Or, better explained, I want an AthensImageReadWriter who answers me a > >> > surface (or something that I can draw with an athens canvas) with the > >> > image > >> > from a file :) > >> > > >> You know that you can convert between forms and athens surface? > >> Forms is actually not that bad, they simply contain bits. > >> The bit format information is a bit obscure (comparing to OpenGL, for > >> instance), > >> but its enough. > >> So, i suggest you to use form and ImageReadWriter. > >> > > > > But reading image from file without smalltalk operations can be much more > > efficient. If your application works extensively with external images It > is > > important. > > That's why I write question at user group about how to get Form > efficiently > > from external memory which filled by FFI call. Unfortunately no answers. > > Now I think about optimisation of PNGImageReadWriter by NativeBoost. > > > > Well, Cairo uses libpng as dependency, and provides easy interface > functions > to create surfaces from png file(s). > But then, what if tomorrow we will use something else than cairo? > In the long run, i think, using libpng directly will be more reasonable. > > But i feel doubly, whether we should rely on it by default. > From other side, our VMs already includes jpeg library.. > I really like all solutions at image side. So I'm not talk about usage some library by default. I just want good option which get best performance and easy to use. > -- > Best regards, > Igor Stasenko. > >

Jan. 23, 2013

Re: [Pharo-project] SmallLint applied on Pharo: Continued

by Hernan Wilkinson

I found an email about this! it is: http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-December/098738… The code is on squeak map ... I did not even remember about squeak map :-) On Wed, Jan 23, 2013 at 11:48 AM, Hernan Wilkinson < hernan.wilkinson(a)10pines.com> wrote: > Hi Stef, > it is great to see that you are using SmallLint to check for errors in > Pharo. I the development process we had in a project I participated, we had > a step where you had to run SmallLint and you could not commit code with > smallLint errors and for some packages with possible errors. > Becuase SmallLint generates a quite a lot false positives, we developed > at that time (it was around 2004) something we called > "ExpectedSmallLintErrors" that we use to document those false positives and > therefore be able to commit the changes (the documentation was smalltalk > code of course that included a reason and an author). The interesting thing > about this kind of doc. was that if the false positive went away you had to > remove the related "expected error", so it worked both ways. > We solved the problems you mentioned about subclass responsibility and > others similars, all with VisualAge > It was really cool and it help us to catch and prevent a lot of errors. > We ported it to Pharo (or Squeak at that time) a long time ago, but I > cannot find the project on SqueakSource... I remember that Lukas had > implemented something similar using pragmas but it lacked some features > that we supported that I don't remember now :-) > > Anyway, I'm really happy to see that the Pharo team is using SmallLint > and I think you should put it as a step in the development process, and I > also recommend to you to have some "interesting" way of documenting false > positive because if not you will end up not using it... at least that was > my experience. > > Bye, > Hernan. > > > On Tue, Jan 22, 2013 at 8:59 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> > Well. I've written the tag support, so let's make it simple, MIT. >> > I may export a changeset with that code for you, if you like. >> >> Else I will just go over them and it will help me to understand. I think >> that this is not difficult. >> >> > For rules written by CG I'm not sure. You should check with him. >> > But I think it won't be a problem given that you preserve all >> > the signatures and #documentation and #version_XXX methods >> > (we use them to track changes in the source). >> > >> > However, what I planned (and run out of time :-) is to make >> > tag a first class object with name (symbol) description etc >> > and have class methods to create them. Then one may define and >> > describe meaning of the tag in an extension method. >> > Also, the selection/rejection logic could dispatch back on >> > the tag instance so you may then create fancy dynamic tags >> > (like #portability that automatically includes everything tagged >> > as #pharo #squeak #stx #va, for instance or whatever. >> > >> > I might hack it later this week, if you would include it into >> > your version (otherwise I've more important things to do :-) >> >> I imagine well. >> Let us keep it simple. Simple tags with a little class comments are good >> enough :) >> >> > >> > Cheers >> > >> > On 22/01/13 19:32, StÃ©phane Ducasse wrote: >> >> Jan >> >> what is the license of your tags and other code? >> >> >> >> Stef >> >> >> >> On Jan 22, 2013, at 3:45 PM, Jan Vrany wrote: >> >> >> >>> On 22/01/13 18:22, StÃ©phane Ducasse wrote: >> >>>> Hi >> >>>> >> >>>> I'm running the rule RBSubclassResponsibilityNotDefinedRule that >> >>>> >> >>>> Checks that all subclassResponsibility methods are defined in all >> leaf classes. >> >>>> >> >>>> Now the results display the sender of ^ subclassResponsibility but I >> have to manually find the >> >>>> problems. I would be better to report the violations. Of course this >> is not that simple: returning a class and missing method. >> >>>> >> >>>> But this would be much better. Jan did you do that in your version? >> >>> >> >>> Good point. Yes, since now we do that :-) >> >>> >> >>> Jan >> >>> >> >>>> >> >>>> Stef >> >>>> >> >>> >> >>> >> >> >> >> >> >> >> > >> > >> >> >> > > > -- > *HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching* > *Phone: +54 - 011 - *6091 - 3125* > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com <http://www.10pines.com/>* > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching* *Phone: +54 - 011 - *6091 - 3125* Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Alem 693, Floor 5 B, Buenos Aires, Argentina

Jan. 23, 2013

Re: [Pharo-project] TalkFFI: automatic FFI generation for Pharo

by Stefan Marr

Hi: On 23 Jan 2013, at 15:28, Stefan Marr wrote: > On 06 Jan 2013, at 17:22, Ciprian Teodorov wrote: >> The project is released under MIT license, and you can find it on the smalltalkhub site. >> http://smalltalkhub.com/#!/~CipT/TalkFFI > > I was trying to play with TalkFFI, but it looks like libclang3.1 is not compiled correctly or something. > > How do you build it? In your code I see you are also targeting OSX, so that doesn't seem to be the problem. > > I was trying to use the MacPorts version of libclang3.1 without having set any special compiler flags. > So, I am not entirely sure whether it is build correctly. I searched a bit more and found the libclang of Xcode (/Developer/usr/clang-ide/lib/libclang.dylib). With that lib it crashes the VM on a callout to parse the header file (clang_createTranslationUnitFromSourceFile). The MacPorts version already stopped way earlier when trying to use clang_createIndex. So, still not a lot of luck. I am on a OSX 10.6 with the latest NBCog, downloaded today (http://pharo.gforge.inria.fr/ci/vm/nbcog/mac/NBCog-mac-latest.zip) Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Jan. 23, 2013

Re: [Pharo-project] SmallLint applied on Pharo: Continued

by Hernan Wilkinson

Hi Stef, it is great to see that you are using SmallLint to check for errors in Pharo. I the development process we had in a project I participated, we had a step where you had to run SmallLint and you could not commit code with smallLint errors and for some packages with possible errors. Becuase SmallLint generates a quite a lot false positives, we developed at that time (it was around 2004) something we called "ExpectedSmallLintErrors" that we use to document those false positives and therefore be able to commit the changes (the documentation was smalltalk code of course that included a reason and an author). The interesting thing about this kind of doc. was that if the false positive went away you had to remove the related "expected error", so it worked both ways. We solved the problems you mentioned about subclass responsibility and others similars, all with VisualAge It was really cool and it help us to catch and prevent a lot of errors. We ported it to Pharo (or Squeak at that time) a long time ago, but I cannot find the project on SqueakSource... I remember that Lukas had implemented something similar using pragmas but it lacked some features that we supported that I don't remember now :-) Anyway, I'm really happy to see that the Pharo team is using SmallLint and I think you should put it as a step in the development process, and I also recommend to you to have some "interesting" way of documenting false positive because if not you will end up not using it... at least that was my experience. Bye, Hernan. On Tue, Jan 22, 2013 at 8:59 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > Well. I've written the tag support, so let's make it simple, MIT. > > I may export a changeset with that code for you, if you like. > > Else I will just go over them and it will help me to understand. I think > that this is not difficult. > > > For rules written by CG I'm not sure. You should check with him. > > But I think it won't be a problem given that you preserve all > > the signatures and #documentation and #version_XXX methods > > (we use them to track changes in the source). > > > > However, what I planned (and run out of time :-) is to make > > tag a first class object with name (symbol) description etc > > and have class methods to create them. Then one may define and > > describe meaning of the tag in an extension method. > > Also, the selection/rejection logic could dispatch back on > > the tag instance so you may then create fancy dynamic tags > > (like #portability that automatically includes everything tagged > > as #pharo #squeak #stx #va, for instance or whatever. > > > > I might hack it later this week, if you would include it into > > your version (otherwise I've more important things to do :-) > > I imagine well. > Let us keep it simple. Simple tags with a little class comments are good > enough :) > > > > > Cheers > > > > On 22/01/13 19:32, StÃ©phane Ducasse wrote: > >> Jan > >> what is the license of your tags and other code? > >> > >> Stef > >> > >> On Jan 22, 2013, at 3:45 PM, Jan Vrany wrote: > >> > >>> On 22/01/13 18:22, StÃ©phane Ducasse wrote: > >>>> Hi > >>>> > >>>> I'm running the rule RBSubclassResponsibilityNotDefinedRule that > >>>> > >>>> Checks that all subclassResponsibility methods are defined in all > leaf classes. > >>>> > >>>> Now the results display the sender of ^ subclassResponsibility but I > have to manually find the > >>>> problems. I would be better to report the violations. Of course this > is not that simple: returning a class and missing method. > >>>> > >>>> But this would be much better. Jan did you do that in your version? > >>> > >>> Good point. Yes, since now we do that :-) > >>> > >>> Jan > >>> > >>>> > >>>> Stef > >>>> > >>> > >>> > >> > >> > >> > > > > > > > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching* *Phone: +54 - 011 - *6091 - 3125* Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Alem 693, Floor 5 B, Buenos Aires, Argentina

Jan. 23, 2013

Re: [Pharo-project] zero conf build

by Igor Stasenko

On 23 January 2013 15:24, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 23 January 2013 14:05, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 23 January 2013 11:08, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> so yeah, looks like the linux VMs won't run anymore under ubuntu 10 >>> >> The software upgrade hit us back. >> Should we install ubuntu 10 slave to build VMs on it? > > At the risk of sounding foolish, is it possible to write the Makefile > to use a particular (and configurable) glibc, rather than the glibc > that just happens to be on a machine? > This is not sounds foolish.. > That way one could use whatever machine, and say "use glibc 2.11". > The last time i faced problem(s) with glibc i found it very non-trivial to have two different versions of it on a system, and i remember i failed back then, trying to convince compiler to use proper version of it.. and then linker and etc.. and i ended up in having so much mess, that at the end i just decided to reinstall a system. :) But it was long ago.. don't know maybe i was doing something foolish and solution is easy (at least today). > frank -- Best regards, Igor Stasenko.

Jan. 23, 2013

Re: [Pharo-project] [ANN] Headless support for Cog Cocoa VM

by Esteban Lorenzano

we have it is just you who cannot :) On Jan 23, 2013, at 3:28 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Wed, Jan 23, 2013 at 11:07 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Hi Mark, > > Should have read the man page for open instead of a web page. > > No problem. > > I had already tried the second version. > Still crashes though, with the same error, on 10.6.8 > (can try it on newer and older versions too, after finding a working version) > > Mariano: CogVM-sandard also has the illegal instruction > > > Ok, the good news for me then is that it is not my headless change but the problem of GNU GCC VS. LLVM GCC ;) > > We need to find a way to compile the VM in 10.8 and with GNU :( > > Stephan > > > > > > > -- > Mariano > http://marianopeck.wordpress.com

Jan. 23, 2013

Re: [Pharo-project] TalkFFI: automatic FFI generation for Pharo

by Stefan Marr

Hi Ciprian: On 06 Jan 2013, at 17:22, Ciprian Teodorov wrote: > The project is released under MIT license, and you can find it on the smalltalkhub site. > http://smalltalkhub.com/#!/~CipT/TalkFFI I was trying to play with TalkFFI, but it looks like libclang3.1 is not compiled correctly or something. How do you build it? In your code I see you are also targeting OSX, so that doesn't seem to be the problem. I was trying to use the MacPorts version of libclang3.1 without having set any special compiler flags. So, I am not entirely sure whether it is build correctly. Any hints are appreciate. Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Jan. 23, 2013

Re: [Pharo-project] [ANN] Headless support for Cog Cocoa VM

by Mariano Martinez Peck

On Wed, Jan 23, 2013 at 11:07 AM, Stephan Eggermont <stephan(a)stack.nl>wrote: > Hi Mark, > > Should have read the man page for open instead of a web page. No problem. > I had already tried the second version. > Still crashes though, with the same error, on 10.6.8 > (can try it on newer and older versions too, after finding a working > version) > > Mariano: CogVM-sandard also has the illegal instruction > > Ok, the good news for me then is that it is not my headless change but the problem of GNU GCC VS. LLVM GCC ;) We need to find a way to compile the VM in 10.8 and with GNU :( Stephan > > > > -- Mariano http://marianopeck.wordpress.com

Jan. 23, 2013

Re: [Pharo-project] zero conf build

by Frank Shearar

On 23 January 2013 14:05, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 23 January 2013 11:08, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> so yeah, looks like the linux VMs won't run anymore under ubuntu 10 >> > The software upgrade hit us back. > Should we install ubuntu 10 slave to build VMs on it? At the risk of sounding foolish, is it possible to write the Makefile to use a particular (and configurable) glibc, rather than the glibc that just happens to be on a machine? That way one could use whatever machine, and say "use glibc 2.11". frank >> you will can find out the last version of GLIBC on your distro by running >> strings /lib/libc.so.6 | grep GLIBC >> >> >> On 2013-01-22, at 17:41, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> For example: >>> >>> curl http://pharo.gforge.inria.fr/ci/script/ciPharo20PharoVM.sh | sh >>> ./vm.sh >>> >>> or: >>> >>> curl http://pharo.gforge.inria.fr/ci/script/ciPharo20CogVM.sh | bash. >>> ./vm.sh >>> >>> Cheers, >>> Doru >> >> > > > > -- > Best regards, > Igor Stasenko. >

Jan. 23, 2013