- Pharo-dev - lists.pharo.org

Re: [Pharo-project] PluggableMultiColumnListMorph example?

by J. P. L. MartÃn

If i have an OrderedCollection(a Prestamo id: '1' idMaterial: 'Book' idSocio: 'User' fechaPrestamo: 7 January 2013 fechaPrevistaDevolucion: 10 January 2013 fechaDevolucion: '') what would be a proper wrap for it if I want a column for each part of the colection? Also, what was the method that control size of the list? Thanks a lot! On Thu, Jan 3, 2013 at 11:18 AM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Load the attached st file > > and execute the following snippet: > > (PluggableMultiColumnListMorph > on: MyModelExample new > list: #list > selected: #selected > changeSelected: #selected: > menu: nil > wrapSelector: #wrap:at:) openInWindow > > > > > > > If you have questions, do not hesitate :) > > Ben > > On Jan 3, 2013, at 2:25 PM, J. P. L. MartÃn wrote: > > > Someone could give me a little example on PluggableMultiColumnListMorph? > Does it work with OrderedCollections? > > > > Thanks in advance! > > >

Jan. 8, 2013

Re: [Pharo-project] FOSDEM 2013 Smalltalk devroom

by Esteban Lorenzano

Hi Stephan, Sorry for came up so late with this, but I remember you asked for some ideas about what to show on FOSDEM... I was on vacations so I didn't answer at the time, but I will try something now, in case is still useful :) I presented Smalltalk some times at non-Smalltalker audiences, last time at fossa [1], with Stef and Marcus. We presented more or less a "showcase" of available technologies present in Pharo (the usual ones. Seaside, Glamour, etc.) but I finished by playing with my examples around athens and chipmunk (the "Storm" project [2], you can see some videos at youtube, if you didn't checked yet [3]). At the end, even if it was interesting to show what technologies are available, the really interesting part for the audience was watching me playing with spheres and physics :) Why that? Well... the fact is with those examples I managed to show the better property that smalltalk has: IMMEDIATE FEEDBACK (another way to say "live environment", that I think is easier to understand for non-Smalltalkers). It was really exciting see the reaction of people when they looked me changing sphere colors, positions, quantities, etc. right in front of them, without re-compiling anything or even stoping the simulation. Remember that video of the guy doing funny stuff with javascript? well... kinda the same but with something that can be really used (the javascript stuff was just a prototype, impossible to download and play with it). So, my advice: no matter what you present, if you focus on those properties of Smalltalk, you will gain a lot of attention :) If you want to play with Storm, you will find the instructions in the smalltalkhub page, and of course I will be happy to help you. Esteban [1] http://fossa.inria.fr/ [2] http://smalltalkhub.com/#!/~estebanlm/Storm [3] http://www.youtube.com/user/estebanlmvideos On Jan 7, 2013, at 4:19 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Rafael wrote: >> I've noticed that FOSDEM 2013 will host an Smalltalk devroom like the >> previous year. Any idea about the scheduled sessions? >> >> I'd like to see tutorials related with Pharo, Seaside, Amber, Moose, etc. > > I'm working on finalizing the schedule now. > We'll have presentation of the current state of Squeak & Pharo, > experience report and getting started with Amber, > the active filesystem, a workshop to get started with Smalltalk development, > might have BabyMock/GOOS, Oak, Altitude & EtoilÃ©,and some more time to talk than > last year. > > I would welcome someone showing Moose. Need to finalize the schedule > soon though. > > Cheers, > Stephan Eggermont > >

Jan. 7, 2013

Re: [Pharo-project] FOSDEM 2013 Smalltalk devroom

by Stephan Eggermont

Rafael wrote: >I've noticed that FOSDEM 2013 will host an Smalltalk devroom like the >previous year. Any idea about the scheduled sessions? > >I'd like to see tutorials related with Pharo, Seaside, Amber, Moose, etc. I'm working on finalizing the schedule now. We'll have presentation of the current state of Squeak & Pharo, experience report and getting started with Amber, the active filesystem, a workshop to get started with Smalltalk development, might have BabyMock/GOOS, Oak, Altitude & EtoilÃ©,and some more time to talk than last year. I would welcome someone showing Moose. Need to finalize the schedule soon though. Cheers, Stephan Eggermont

Jan. 7, 2013

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

by GÃ¶ran Krampe

Hey! On 01/06/2013 05:22 PM, Ciprian Teodorov wrote: > Happy new year everybody! > > I am pleased to announce today the initial release of TalkFFI. Wow! I have been waiting for something "SWIG" like for Squeak/Pharo since... hell, I dunno, since like ever. ;) This kind of stuff might very well be the most important "piece" of the puzzle when it comes to *really* growing Pharo outside of the general Smalltalk community. regards, GÃ¶ran

Jan. 7, 2013

Re: [Pharo-project] About morph layout

by Fernando Olivero

Hi, a couple of years ago, i tried to port Small Morphic from CUIS to Pharo1.2. After a couple of weeks i gave up, because there are to many relations between the UI framework and the underlying system, which made it not just a matter of UI porting, but a complete system diff. Morphic relies on some kernel graphics which slightly differ in both systems (Form, Canvas, etc..), and on the base object model infrastructure, and some IDE related objects such as SystemNavigation , UIManager, etc.. I prefer the approach taken by Stef and other community members, clean the current system one step at a time. Maybe, there will be some overlapping with Juan's great work on CUIS, but on the bright side you wont get burned trying to port, manage, and plug a new Morphic into Pharo. Fernando pd: It was so hard, i decided to start a new UI framework from the ground up. On Wed, Jan 2, 2013 at 7:52 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > Craig's NAIAD stands for "Name And Identity Are Distinct". Just > thinking aloud -- because Morphic is so entrenched.. Could NAIAD or > Colin's Environments allow Juan's Morphic (or, Morphic3) to co-exist > with original Morphic, so that it would allow working on the port > without depending on it for the tools? Once the port was complete, a > sane migration could more easily occur.. > > > On Wed, Jan 2, 2013 at 7:00 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > On 2 January 2013 12:55, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > >> Hello again Igor > >> and Happy and Successful New "Pharo" Year 2013 > >> > > > > Thanks Hannes :) > > Wish best to you in New Year too :) > > > > > >> --Hannes > >> > >> my notes are inserted below. > >> > >> > >> On 12/24/12, Igor Stasenko <siguctua(a)gmail.com> wrote: > >>> On 24 December 2012 09:43, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > >>>> Hello Igor > >>>> > >>>> Thank you for this interesting mail. An issue over 11 years old, see > >>>> below. > >>>> > >>>> On 12/24/12, Igor Stasenko <siguctua(a)gmail.com> wrote: > >>>>> Hi, > >>>>> > >>>>> just wanna share some ideas about how we can cleanup morph a bit. > >>>> > >>>> A bit? > >>>> It will be a lot of effort. > >>>> > >>> We can do it in small steps. > >>> > >>>> Squeak 4.4-12234 (current) > >>>> > >>>> Morph selectors size 1183 > >>>> > >>>> > >>>> Pharo 2.0 (Beta) > >>>> > >>>> Morph selectors size 865 > >>>> > >>>> > >>>> Cuis 4.1 (18th Dec 2012) > >>>> > >>>> Morph selectors size 343 > >>>> > >>>> > >>>> This was an issue in 2001 > >>>> > >>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2001-June.txt > >>>> > >>>> see > >>>> > >>> I am not first day here, of course i am aware of this :) > >> > >> Did you start working with Squeak already in 2001? > >> > > no. But i know this is a long standing issue :) > > > >>>>> Layout.. bizarre. > >>>> > >>>> Yes, see humorous contribution from June 2001 > >>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2001-June.txt > >>>> > >>>> search for > >>>> > >>>> the Morph class has 924 methods > >>>> > >>>> in that mails > >>>> > >>>> There was an effort > >>>> Morphic Cleanup Project > >>>> > >>>> http://wiki.squeak.org/squeak/3005 > >>>> > >>>> lead by > >>>> > >>>> Diego Gomez Deck > >>>> > >>>> It produced some results. But they did not reach far enough. > >>>> > >>> yes yes.. i know. > >>> > >>>> However Juan Vuletic was successful in coming up with a simpler > Morphic in > >>>> Cuis. > >>>> > >>>> http://www.jvuletich.org/Cuis/Index.html > >>>> > >>> search this mailing list for Small Morphic. > >>> It was an attempt to use Juan's work, which didn't fly. > >> > >> Of course I am aware of SmallMorphic. If a first attempt at > >> integrating SimpleMorphic into Pharo was not successful it does not > >> necessarily mean that a second one has to be a failure again. > >> > >> Time spent on an analysis why it didn't fly is surely not a waste. > >> > >> For example another approach could be instead of copying code from > >> Cuis and implanting it into Pharo "blob style" you could follow Juan > >> Vuletich's refactoring steps incrementally and copy smaller chunks of > >> code. Cuis had many releases until it reached version 4.1. > >> > >> In terms of factoring out classes from the class Morph you seem to > >> want to do that anyway. > >> > >> See for example > >> > >> http://www.jvuletich.org/Cuis/CuisReleaseNotes.html > >> New in Cuis 2.7 (released September 3, 2010) > >> > >> * Morphic. New LayoutSpec mechanism. Simpler and nicer. > >> * Morphic Simplification: Layout, Extensions, etc > >> > > > > Well, one thing is that Juan doing quite radical changes to code. > > He is not concerned about backwards compatibility (but unlike from > Pharo, nobody > > raising it as an issue over and over again ;) ). > > Yes, i checked new Cuis code. > > I see a lot of simplifications. But also i see reduced functionality. > > For instance, i did not found things like 'fill style', and themes. > > Also, i see some protocols is renamed, in preparation for something > > bigger (morphic 3 i guess ;) > > > > So, i agree we should not copy/paste the code. Because it won't fly. > > We should gradually analyze it and improve ours step by step. > > > > Layout code in Cuis is somewhat similar to what i proposing. > > But my proposal is essentially about approach, which you can apply to > > anything.. not just layouts in Morphics. > > > >>>>> There are so many methods dedicated to laying out morphs that it easy > >>>>> to get lost. > >>>> > >>>> Cuis has a new layout system. > >>>> > >>>> Worth to check out. > >>>> > >>> Sure. > >> > >> Fine. > >> > >>> > >>>>> For me the main mystery and source of confusion is that there > actually > >>>>> two different groups: > >>>>> > >>>>> - methods to control morph's own layout (in respect to its parent) > >>>>> - methods to control morph's children layout (something called > >>>>> layoutPolicy) > >>>>> > >>>>> the problem is that both APIs are found in single class, > >>>> > >>>> which one? > >>>> > >>> Morph > >>> > >>>> and most of > >>>>> them contain 'layout' word in it, > >>>>> so it is really hard to determine which one to use and when.. > >>>>> > >>>>> Over a years, i seen that people learned how to use existing > >>>>> functionality, without delving deep into > >>>>> implementation detail. > >>>> > >>>> Yes. > >>>> > >>>>> But if you try to extend/change behavior (in your subclass), you will > >>>>> quite soon find out that it is really > >>>>> hard to tell with 100% certainty that the methods you override is the > >>>>> right place for your customization. > >>>> > >>>> Yes, this actually has made development very difficult. In such a way > >>>> that most people have abandoned it. Very few GUIs are actually built > >>>> with it. > >>>> > >>>> > >>>>> Also, an important detail is extremely polluted protocol(s), making > >>>>> Morph a GOD class, > >> > >> Morph is at the root of a large subclasses tree. The question is: what > >> can be pushed down or factored out. An analysis in terms of number of > >> method candidates to move out would surely be a good thing to know. > >> > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > >

Jan. 7, 2013

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

by Igor Stasenko

On 7 January 2013 12:38, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > hi Igor, > > Yes I have tried some little external libraries, nothing big yet (besides > llvm, and libclang). For the moment I did not see any show-stopper > problems... But there are still some rough edges. What I have under scrutiny > right now are: > - adding unions to NB > - supporting vectors (and constant arrays, which are flattened right now). > Vectors appear to be used in cblas. > - there are some problems with my callback naming scheme, which I found > trying to map Cairo. > > Besides these there are some improvements to NB, to simplify code generation > and maintenance like: > - an unified parser for the simplified c declarations. > - unifying fieldDecl, enumDecl, fnSpec under a single naming convention... > Maybe nativeSpec, or nativeDecl > Feel free to discuss the details. Getting NB more feature-complete won't hurt anyone :) > For the customizations I think right now is to early to say that I have a > good interface. But certainly over time we will have different filters. > Right now you can customize fct names using a block, and u can specify a > prefix for the generated classes. > > I am also thinking about a graphical interface, somewhat on the lines of the > dllcc in vw. > > Anyways I think using libclang offers nice opportunities, maybe retrieving > comments from headers, or even autocomplete-like ffi generation... > > So yeah for now I will call TalkFFI a tech-preview... We will see how it > goes ;) > Yes, we should start from somewhere, and it looks like a good starting point. About customizations, i was thinking about SWIG-style customization where you can write-down a list of rules, how you would like to generate bindings to some concrete library + target language etc. Since depending on the library, you will need some adjustments here or there, you will find that we're need that inevitably. > Cheers > > On Jan 7, 2013 1:13 AM, "Igor Stasenko" <siguctua(a)gmail.com> wrote: >> >> Wow.. that's great. >> Having a way to automatically generate bindings makes life much easier :) >> >> Few questions: >> - did you tried to run it against some libraries around there, except >> from LLVM? >> >> - i saw, in video, you can customize generation a bit.. to what >> extent? Is there interface >> (suppose i want to use own naming prefix, suppress generation of >> certain declaration etc)? >> >> -- >> Best regards, >> Igor Stasenko. >> -- Best regards, Igor Stasenko.

Jan. 7, 2013

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

by Ciprian Teodorov

hi Igor, Yes I have tried some little external libraries, nothing big yet (besides llvm, and libclang). For the moment I did not see any show-stopper problems... But there are still some rough edges. What I have under scrutiny right now are: - adding unions to NB - supporting vectors (and constant arrays, which are flattened right now). Vectors appear to be used in cblas. - there are some problems with my callback naming scheme, which I found trying to map Cairo. Besides these there are some improvements to NB, to simplify code generation and maintenance like: - an unified parser for the simplified c declarations. - unifying fieldDecl, enumDecl, fnSpec under a single naming convention... Maybe nativeSpec, or nativeDecl For the customizations I think right now is to early to say that I have a good interface. But certainly over time we will have different filters. Right now you can customize fct names using a block, and u can specify a prefix for the generated classes. I am also thinking about a graphical interface, somewhat on the lines of the dllcc in vw. Anyways I think using libclang offers nice opportunities, maybe retrieving comments from headers, or even autocomplete-like ffi generation... So yeah for now I will call TalkFFI a tech-preview... We will see how it goes ;) Cheers On Jan 7, 2013 1:13 AM, "Igor Stasenko" <siguctua(a)gmail.com> wrote: > > Wow.. that's great. > Having a way to automatically generate bindings makes life much easier :) > > Few questions: > - did you tried to run it against some libraries around there, except > from LLVM? > > - i saw, in video, you can customize generation a bit.. to what > extent? Is there interface > (suppose i want to use own naming prefix, suppress generation of > certain declaration etc)? > > -- > Best regards, > Igor Stasenko. >

Jan. 7, 2013

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

by Igor Stasenko

Wow.. that's great. Having a way to automatically generate bindings makes life much easier :) Few questions: - did you tried to run it against some libraries around there, except from LLVM? - i saw, in video, you can customize generation a bit.. to what extent? Is there interface (suppose i want to use own naming prefix, suppress generation of certain declaration etc)? -- Best regards, Igor Stasenko.

Jan. 7, 2013

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

by StÃ©phane Ducasse

> > Yes a tutorial will come too ... but first I want to test it a little more, and maybe get some feedback from volunteers ;) excellent! For the video, may be use larger fonts. > I will have to check if it works on other platforms besides my mac. > Then figure a way to package/distribute easily with libclang - since compiling libclang might not be trivial for a user. > > Moreover If any of you guys have comments, different usage scenarios, api improvement ideas please don't hesitate. > > Cheers, > Ciprian > > Stef > > > > Happy new year everybody! > > > > I am pleased to announce today the initial release of TalkFFI. > > > > TalkFFI enables automatic FFI generation for Smalltalk. > > It uses libclang to parse unmodified C header files and generate FFI bindings to c libraries. > > For now it supports the generation of NativeBoost FFI bindings. > > > > The project is released under MIT license, and you can find it on the smalltalkhub site. > > http://smalltalkhub.com/#!/~CipT/TalkFFI > > > > Please do not hesitate send me your comments/critics/ideas. > > > > Best regards, > > -- > > Dr. Ciprian TEODOROV > > IngÃ©nieur DÃ©veloppement CAO > > > > tÃ©l : 06 08 54 73 48 > > mail : ciprian.teodorov(a)gmail.com > > www.teodorov.ro > > > > > > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro

Jan. 6, 2013

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

by Ciprian Teodorov

On Sun, Jan 6, 2013 at 7:31 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Thanks Ciprian. It is a nice extension :). > we should write a little tutorial :) > Yes a tutorial will come too ... but first I want to test it a little more, and maybe get some feedback from volunteers ;) I will have to check if it works on other platforms besides my mac. Then figure a way to package/distribute easily with libclang - since compiling libclang might not be trivial for a user. Moreover If any of you guys have comments, different usage scenarios, api improvement ideas please don't hesitate. Cheers, Ciprian > > Stef > > > > Happy new year everybody! > > > > I am pleased to announce today the initial release of TalkFFI. > > > > TalkFFI enables automatic FFI generation for Smalltalk. > > It uses libclang to parse unmodified C header files and generate FFI > bindings to c libraries. > > For now it supports the generation of NativeBoost FFI bindings. > > > > The project is released under MIT license, and you can find it on the > smalltalkhub site. > > http://smalltalkhub.com/#!/~CipT/TalkFFI > > > > Please do not hesitate send me your comments/critics/ideas. > > > > Best regards, > > -- > > Dr. Ciprian TEODOROV > > IngÃ©nieur DÃ©veloppement CAO > > > > tÃ©l : 06 08 54 73 48 > > mail : ciprian.teodorov(a)gmail.com > > www.teodorov.ro > > > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Jan. 6, 2013