August 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [croquet-dev] Re: [squeak-dev] Second LIfe plugin API

by Lawson English

Howard Stearns wrote: > Cool. What do you have in mind? > > Do you have any experience with the QuickTime media plugin? How is it > in general? How is it for streaming sources? > > The model for coordinating plugin activity across clients was not > clear to me. E.g., if I fire up QuickTime for a movie, how do all > other clients in the sim (that happen to have the plugin installed) > get coordinated to the same place in the movie? > > > Howard Stearns > Qwaq: +1-650-331-1437 > mobile: +1-608-658-2419 > > The way it works right now (and in the future unless they change things), a land-owner can set a "parcel media" URL which is the URL to a streaming media server that will play on any local object that displays a certain texture. The plugin API extends that to allow for custom plugins to run, but only in the context of the parcel media URL texture. I can imagine many cases where a media plugin served from localhost might be useful. It should be possible to specify localhost as a valid url for media-on-a-prim (HUD at least) that is settable separately from, or as an alternative to, the parcel media URL. IOW, if I install a custom HUD with a localhost url as the parcel media url, I should be able to interact with a private plugin running/streaming on my own comp. E.G. a seaside server on localhost doing all sorts of spiffy things that I haven't thought of yet. The plugin API makes it easy to have a plugin be part of the second life world, as far as GUI is concerned. I'm trying to convince people to create another message/event mechanism to allow more direct interaction with the SL viewer. IE, use Squeak as a scripting plugin on the viewer side. One could use the media API to provide a GUI and use the events API to send commands for generic scripting of the SL viewer. Lawson

Aug. 18, 2009

Re: [Pharo-project] Native Windows

by Gary Chambers

I'll keep checking ,but, let me know when the basics are in and I'll provide support in Polymorph. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, August 18, 2009 4:11 PM Subject: Re: [Pharo-project] Native Windows > 2009/8/18 Eagle Offshore <eagleoffshore(a)mac.com>: >> I'm curious why you did a new plugin. Does the existing one not work >> on windows? >> > it works , but it duplicating a functionality which also present in > core platform files: > - creating a window > - processing events > > so, the idea is to merge & unify all these bits into a single plugin > and also, make an extended API for > managing host windows. > >> I got the following from Bert on the state of the unix plugin: >> >> "The plugin functions are still stubbed out, so you cannot actually >> open a second window, yet. But at least the hairy part of the work is >> done - I implemented the dispatching between the HostWindow plugin to >> the various display modules. This is more complex than on the other >> platforms, because the unix VM so far supports X11, Quartz, >> FrameBuffer, and Null display devices. But I did that part, now >> someone can simply implement e.g. the X11 functions to have it working >> in Linux. The only function I actually implemented was changing the >> title of the main Squeak window (window index 1). >> " >> >> -Todd Blanchard >> >> On Aug 18, 2009, at 6:03 AM, Igor Stasenko wrote: >> >>> 2009/8/18 John M McIntosh <johnmci(a)smalltalkconsulting.com>: >>>> Before you run too far down the let's change Morphic path you should >>>> check with Igor I'm sure he was off a year back trying to hack >>>> Ffenestri into Morphic. >>>> >>> yes, yes i have an initial implementation of new hostwindows plugin >>> which moves/separates the windowing stuff from core VM functionality. >>> >>> It then would be possible to build a VM which having no windowing >>> support at all, and works as a console application. >>> >>> The problem with it, that i never did any windowing & event handling >>> on X windows or MacOS, >>> so its not so easy. I'm only hoping that my design fits well with >>> other platforms, not only win32. >>> >>> I can publish the bits i'm done. Just say. >>> I am swamped by another projects , so i don't know when i could find a >>> time to finish it. :( >>> >>>> Tim and I gave that thought up when we considered there was 400 or so >>>> references to EventSenor & Display many of which had no concept of >>>> window ownership in mind. >>> >>> Yes, this is a bit of pain. >>> My thought about it, is to keep sensor global, but >>> replace all refs to Display to 'self display' message send. >>> There are only a few methods which assigning new value to Display , >>> which should be addressed separately. >>> >>> >>>> >>>> >>>> On 17-Aug-09, at 6:27 PM, Eagle Offshore wrote: >>>> >>>>> Thanks so much for sharing on this. >>>>> >>>>> There seems to be a few caches of stuff stashed in various places. >>>>> None of it is exactly complete. I've taken the bulk of it from >>>>> the http://source.impara.de/HostWindows >>>>> and a bit from your experimental directory and looked at the plugins >>>>> code in the VM tree and then just started trying to fix problems >>>>> with event delivery. I'd like to pull it all together and make it >>>>> coherent on Windows, OS X and Unix. >>>>> >>>>> Its really great that Pharo has integrated the HostMenus stuff - I >>>>> think it would be cool to do HostWindows too. Once you eliminate >>>>> having to emulate the look of the windows - most widget sets look >>>>> pretty similar and I think morphic widgets inside of real windows >>>>> would keep things from looking too weird while preserving the >>>>> benefits of having our widgets in Smalltalk. >>>>> >>>>> Given Pharo's "take no prisoners" attitude, I think getting host >>>>> windows working would allow a lot of really ugly code in >>>>> PasteUpMorph and HandMorph to just go away. Event delivery in >>>>> Morphic is just totally incomprehensible and I'm finding it is >>>>> broken when a second window is introduced as the mouse coordinates >>>>> seem to be delivered window relative. Its also really hard to work >>>>> on because I keep junking images by making changes that wreck the >>>>> UI. >>>>> >>>>> -Todd Blanchard >>>>> >>>> >>>> -- >>>> = >>>> = >>>> = >>>> = >>>> = >>>> = >>>> ===================================================================== >>>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >>>> squeaker68882 >>>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>>> = >>>> = >>>> = >>>> = >>>> = >>>> = >>>> ===================================================================== >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 18, 2009

[Pharo-project] Second LIfe plugin API

by Lawson English

As part of my on-going work on finding synergy, someone, somewhere, might want to look at this: http://wiki.secondlife.com/wiki/Media_Rendering_Plugin_Framework_Technical_… and consider what might be done with Squeak/Phara/Croquet/Cobalt/Seaside in a Second Life context. Lawson

Aug. 18, 2009

Re: [Pharo-project] ORM for Pharo -- Â½ OFF

by Mariano Martinez Peck

On Tue, Aug 18, 2009 at 10:37 AM, Esteban A. Maringolo <emaringolo(a)gmail.com > wrote: > I'm arriving late to this discussion... > > I think that having a good ORM solution is important to enterprise > applications... and not only enterprise but if you have tables with > LOTS of rows, you need to map them to objects. Don't start talking > about Gemstone, I like, it's rock solid, but sometimes, most of the > times I would say, it's out of the discussion. > > Even with objects mapped to tables, you can do real good object > programming. > > I don't want to see another isolated Smalltalk again, the more able > you are to interconnect with the external world, the better. This is not the case of Pharo. As you may know, most of the ESUG people are under the Pharo project. ESUG has selected SqueakDBX as a SummerTalk project and has sponsored us, not only in 2008 but again this year. See: http://www.esug.org/Promotion/SummerTalk So, you should notice that at least ESUG is interested in relational database access. Best, Mariano > > > Regards, > > Esteban A. Maringolo > > > > 2009/8/16 Carlos Crosetti <carlos(a)mostar.com.ar>: > > IMHO Pharo must stick to the roadmap milestones, keeping clear boundaries > on > > what goes in and out - I value that some people are acting as > gatekeepers. > > > > Then a second community, those who develop frameworks that run on top of > > Pharo, like the authors of frameworks of Seaside, Glorp,,SqueakDBX (to > name > > a few coming from the top of my head) may probably try to ensure their > > frameworks progresses aligned with the Pharo releases, demanding a > rrobust > > and performant Smalltalk system impementattion. > > > > Now, to boost Pharo adoption, beyod smalltalkers, and to capture the > > attention of new people, probably not familiar with the language, > > technology, style, the system itself, the paradigm, and (why not) the > > culture,, a new foundation of spin-off should address the level of effort > to > > envision and manufacture... > > #1 a rich set of widgets and > > #2 recipes showing how to combine them to produce high-impact realtime > > client GUIs > > > > As an example I mention what > > - Swing, AWT and SWT is for Java, > > - Tk is for Tcl, > > - GTK+ to C++, (and lots of....) > > - UIPaainter to VisualWorks, > > > > and so on..:) > > > > -----Mensaje original----- > > De: pharo-project-bounces(a)lists.gforge.inria.fr > > [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de > > csrabak(a)bol.com.br > > Enviado el: SÃ¡bado, 15 de Agosto de 2009 01:04 p.m. > > Para: Pharo-project(a)lists.gforge.inria.fr > > Asunto: Re: [Pharo-project] ORM for Pharo -- Â½ OFF > > > > Mariano, > > > > I can understand the goal be Pharo idea and goal as you post. What I'm > > trying to bring (and hopefully add to this discussion) is how can we > arrive > > there. > > > > We need to narrow down the definition of "enterprise application" and see > > where Pharo can start to thrive. No all encompassing approach would work > as > > notwithstanding how poweful and complete Pharo could become it will not > be > > anytime soon. > > > > The notion that Pharo be not assotiated per se to any UI it is a strong > (and > > I vote to maintain it) design goal but in order to push forward Pharo > > together with robust and clean implementation we'll need a lot of energy > and > > effort to produce enough educational materials like tutorial, manuals, > etc., > > it will be confusing all the time have an example that do not work in > > another minor variation of UI (to stay in a single topic). > > > > So I return to the point: we need to have more clear goals on what > > particular realm we see Pharo as feasible for enterprise development and > be > > able to enumerate what are the advantages of Pharo versus the other > > approaches. > > > > Hope it is more explicit now ;-) > > > > Em 14/08/2009 20:42, Mariano Martinez Peck < marianopeck(a)gmail.com > > > escreveu: > > > > > > 2009/8/14 <csrabak(a)bol.com.br> > >> > >> Mariano, > >> > >> I agree (and I myself have been on the Research side getting answers > >> similar to those ones) in fact I'll add another item to your list: > >> > >> -- They have an "architectural steering committee" that dictates use of > >> some RDBS > >> > >> I've seen this even requiring some ERP used different database engine > thas > >> suggested by supplier. . . > >> > >> So if we want to compete with enterprise applications we need to get > into > >> some Enterprise: > >> > >> We're still thinkering with printing in Pharo (and this is PITA when > >> attempting to be platform agnostic), so no Report Generator still, no > matter > >> how well you connect to a RDBS, any slightly above trivial example CRUD > >> application will need this support. > >> > >> Our present set of widgets is sleek but still not as comprehensive as > the > >> other competing approaches, and we still have not created enough > baseline to > >> have an "echo system" so third parties can augment them as it happens > now > >> with Java, .Net and happened (and still as legacy updates) in Delphi and > VB. > >> > >> So if the goal is to reach those enterprise trench we have to find some > >> company that would profit of having [Pharo] Smalltalk as a primary > language > >> to customize or augment their system, as today (say as sake of example, > SAP > >> has ABAP but with Netweaver is going Java, and they competitors similar > >> path). > >> > >> Let's think about this: historically some (comercial) Smalltalks allowed > >> via OLE (a.k.a. COM, etc.) to access Microsoft Office features and do > things > >> similar as VB (in fact even Tcl and Python allow that), but what is the > >> "productivity" of programmer that finds a tutorial or an example in VB > and > >> has to "translate" it to Smalltalk? > >> > >> As today can we enumerate what would be an advantage of doing something > in > >> Pharo instead of some "mainstream" language just to do some GUI painting > >> CRUD application? > > > > I don't know if I understand you. The idea and goal behind Pharo is to > have > > the open, free, clean and robust smalltalk that we were missing for years > > for commercial applications. At least that's my idea of Pharo. It must be > a > > platform and a base where you can create tools in it and with both of > them > > create real applications. > > > > In my opinion Pharo shouldn't be associated with a particular UI (web or > > desktop) neither to a persistence strategy. Pharo must be the base of all > > that. So then you can have differents alternatives: For UI's you can have > > PolyMorph and the UI Builder. For Web you can have Seaside and Aida/Web. > But > > pharo is not coupled with any of them. You will then choose the solutions > > that best feets your needs. > > > > In summary, I would love to use Pharo as platform to build enterprise and > > commercial applications. No matter how do I persist or display my > objects. > > > > Best, > > > > Mariano > > > > > >> > >> > >> again my 0.01999.... > >> > >> Regards, > >> > >> -- > >> > >> Cesar Rabak > >> > >> > >> > >> Em 14/08/2009 16:57, Mariano Martinez Peck < marianopeck(a)gmail.com > > >> escreveu: > >> > >> > >> 2009/8/14 <csrabak(a)bol.com.br> > >>> > >>> Esteban, > >>> > >>> I'm comenting this on philosophical grounds. > >>> > >>> I understand the efforts to have SqueakDBX and other ORM in Pharo are > >>> motivated by Seaside and other "production" initiatives so, again, my > food > >>> for thought is more an intellectual contribution which I see as useful > for > >>> Pharo as project: > >>> > >>> I don't see Pharo any time soonÂ® having all the toolset to be able to > >>> compete in the CRUDÂ¹ realm with more streamlined tools and besides, not > >>> matter how much theoretical work has been done on ORM, the "impedance > >>> mismatch" is still there, > >> > >> Hi! I am agree with you about the "impedance mismatch". I think that if > I > >> am free to choose a persistence strategy I would use an OODB. However, > if we > >> are talking about real enterprise application (not a simple webpage) > being > >> able to choose the persistence strategy is practically impossible. We > did a > >> survey last year and the results were that most of the times you cannot > >> choose. Of course, the client has a lot of reasons: > >> > >> - The client already has a RDBMS > >> - They had paid for it and have the license (sometimes) > >> - They want a company's support. The only company here is Gemstone. > >> - RDBMS has history and it is an standard > >> - They have knowledge about it > >> - Interaction with other system (even legazy systems) > >> - They are afraid of using another persistence strategy > >> - They want to use SQL > >> - They have DBAs > >> - The persistence is difficult to negotiate > >> > >> So. In my opinion, if Pharo wants to be used really as a platform for > >> enterprise applications (competing to java, .NET, etc), it must have a > good > >> relational solution. Of course, when you are able to choose, you can go > for > >> another approach like OODB. > >> > >> Best, > >> > >> Mariano > >>> > >>> a recent and practicall account of this (for Squeak) can be found in > >>> > >>> http://onsmalltalk.com/simple-image-based-persistence-in-squeak > >>> > >>> also, AIDA/Web has been able to run only storing thing in the image! > See > >>> > >>> > >>> > http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/d3b… > >>> > >>> Since we'll increase the educational efforts to spread Pharo, I think > >>> that as technology we should to recover a bit of Smalltalk technology > and be > >>> first more Object Oriented and then see if ORM still is so needed. > >>> > >>> my 0.0199999.... > >>> > >>> -- > >>> > >>> Cesar Rabak > >>> > >>> [1] http://en.wikipedia.org/wiki/Create,_read,_update_and_delete > >>> Em 14/08/2009 16:14, Esteban A. Maringolo < emaringolo(a)gmail.com > > >>> escreveu: > >>> > >>> My prototype is getting less proto, and I found out it doesn't have > >>> complex relations, and the system is going to perform faster if I have > >>> tables for most of it. > >>> > >>> What are the choices I have for doing ORM in Pharo? > >>> > >>> Â¿Does GLORP work? Â¿Any other options? > >>> I don't have a strong preference for the RDBMS engine, it can be > >>> anything (free), being it MySQL, PostgreSQL or Sql Server Express. > >>> > >>> Best regards, > >>> > >>> Esteban A. Maringolo > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 18, 2009

Re: [Pharo-project] ORM for Pharo

by Mariano Martinez Peck

On Tue, Aug 18, 2009 at 10:55 AM, Esteban A. Maringolo <emaringolo(a)gmail.com > wrote: > SqueakSave seems to bee pretty attractive, does it work in Pharo? > hehehehe I did the same question to him. Actually, I have been sending several private emails with hie because as SqueakSave works for PostgreSQL and MySQL native drivers he had to do a lot of effort. Now, he thought to replace all that stuff with SqueakDBX. Regarding to your question, he told me he didn't tested yet, but wanted to do it before ESUG (he also goes there). But we can ask him again if it was tested. However, take into account this project is still in development, not productive. But sound REALLY interesting. They have a lot of people using it there. It seems to be a very good solution for small/medium app where I don't want to spend time doing mappings, something like active record ? > > Shouldn't it be PharoSave? :) > I am sorry I am not agree. I, as a software developer, would like that my project works not only in Pharo but also in all of its forks. SqueakDBX runs in Squeak, Pharo and (I didn't test it) but should work in Cuis (and if not, let me know please) or whatever other squeak fork. I put the name of the abstract class ;) Cheers, Mariano > Regards! > > Esteban A. Maringolo > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 18, 2009

Re: [Pharo-project] Native Windows

by Igor Stasenko

2009/8/18 Eagle Offshore <eagleoffshore(a)mac.com>: > I'm curious why you did a new plugin. Â Does the existing one not work > on windows? > it works , but it duplicating a functionality which also present in core platform files: - creating a window - processing events so, the idea is to merge & unify all these bits into a single plugin and also, make an extended API for managing host windows. > I got the following from Bert on the state of the unix plugin: > > "The plugin functions are still stubbed out, so you cannot actually > open a second window, yet. But at least the hairy part of the work is > done - I implemented the dispatching between the HostWindow plugin to > the various display modules. This is more complex than on the other > platforms, because the unix VM so far supports X11, Quartz, > FrameBuffer, and Null display devices. But I did that part, now > someone can simply implement e.g. the X11 functions to have it working > in Linux. The only function I actually implemented was changing the > title of the main Squeak window (window index 1). > " > > -Todd Blanchard > > On Aug 18, 2009, at 6:03 AM, Igor Stasenko wrote: > >> 2009/8/18 John M McIntosh <johnmci(a)smalltalkconsulting.com>: >>> Before you run too far down the let's change Morphic path you should >>> check with Igor I'm sure he was off a year back trying to hack >>> Ffenestri into Morphic. >>> >> yes, yes i have an initial implementation of new hostwindows plugin >> which moves/separates the windowing stuff from core VM functionality. >> >> It then would be possible to build a VM which having no windowing >> support at all, and works as a console application. >> >> The problem with it, that i never did any windowing & event handling >> on X windows or MacOS, >> so its not so easy. I'm only hoping that my design fits well with >> other platforms, not only win32. >> >> I can publish the bits i'm done. Just say. >> I am swamped by another projects , so i don't know when i could find a >> time to finish it. :( >> >>> Tim and I gave that thought up when we considered there was 400 or so >>> references to EventSenor Â & Display many of which had no concept of >>> window ownership in mind. >> >> Yes, this is a bit of pain. >> My thought about it, is to keep sensor global, but >> replace all refs to Display to 'self display' message send. >> There are only a few methods which assigning new value to Display , >> which should be addressed separately. >> >> >>> >>> >>> On 17-Aug-09, at 6:27 PM, Eagle Offshore wrote: >>> >>>> Thanks so much for sharing on this. >>>> >>>> There seems to be a few caches of stuff stashed in various places. >>>> None of it is exactly complete. Â I've taken the bulk of it from >>>> the http://source.impara.de/HostWindows >>>> and a bit from your experimental directory and looked at the plugins >>>> code in the VM tree and then just started trying to fix problems >>>> with event delivery. Â I'd like to pull it all together and make it >>>> coherent on Windows, OS X and Unix. >>>> >>>> Its really great that Pharo has integrated the HostMenus stuff - I >>>> think it would be cool to do HostWindows too. Â Once you eliminate >>>> having to emulate the look of the windows - most widget sets look >>>> pretty similar and I think morphic widgets inside of real windows >>>> would keep things from looking too weird while preserving the >>>> benefits of having our widgets in Smalltalk. >>>> >>>> Given Pharo's "take no prisoners" attitude, I think getting host >>>> windows working would allow a lot of really ugly code in >>>> PasteUpMorph and HandMorph to just go away. Â Event delivery in >>>> Morphic is just totally incomprehensible and I'm finding it is >>>> broken when a second window is introduced as the mouse coordinates >>>> seem to be delivered window relative. Â Its also really hard to work >>>> on because I keep junking images by making changes that wreck the >>>> UI. >>>> >>>> -Todd Blanchard >>>> >>> >>> -- >>> = >>> = >>> = >>> = >>> = >>> = >>> ===================================================================== >>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Â Twitter: >>> squeaker68882 >>> Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com >>> = >>> = >>> = >>> = >>> = >>> = >>> ===================================================================== >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Aug. 18, 2009

Re: [Pharo-project] Native Windows

by Eagle Offshore

I'm curious why you did a new plugin. Does the existing one not work on windows? I got the following from Bert on the state of the unix plugin: "The plugin functions are still stubbed out, so you cannot actually open a second window, yet. But at least the hairy part of the work is done - I implemented the dispatching between the HostWindow plugin to the various display modules. This is more complex than on the other platforms, because the unix VM so far supports X11, Quartz, FrameBuffer, and Null display devices. But I did that part, now someone can simply implement e.g. the X11 functions to have it working in Linux. The only function I actually implemented was changing the title of the main Squeak window (window index 1). " -Todd Blanchard On Aug 18, 2009, at 6:03 AM, Igor Stasenko wrote: > 2009/8/18 John M McIntosh <johnmci(a)smalltalkconsulting.com>: >> Before you run too far down the let's change Morphic path you should >> check with Igor I'm sure he was off a year back trying to hack >> Ffenestri into Morphic. >> > yes, yes i have an initial implementation of new hostwindows plugin > which moves/separates the windowing stuff from core VM functionality. > > It then would be possible to build a VM which having no windowing > support at all, and works as a console application. > > The problem with it, that i never did any windowing & event handling > on X windows or MacOS, > so its not so easy. I'm only hoping that my design fits well with > other platforms, not only win32. > > I can publish the bits i'm done. Just say. > I am swamped by another projects , so i don't know when i could find a > time to finish it. :( > >> Tim and I gave that thought up when we considered there was 400 or so >> references to EventSenor & Display many of which had no concept of >> window ownership in mind. > > Yes, this is a bit of pain. > My thought about it, is to keep sensor global, but > replace all refs to Display to 'self display' message send. > There are only a few methods which assigning new value to Display , > which should be addressed separately. > > >> >> >> On 17-Aug-09, at 6:27 PM, Eagle Offshore wrote: >> >>> Thanks so much for sharing on this. >>> >>> There seems to be a few caches of stuff stashed in various places. >>> None of it is exactly complete. I've taken the bulk of it from >>> the http://source.impara.de/HostWindows >>> and a bit from your experimental directory and looked at the plugins >>> code in the VM tree and then just started trying to fix problems >>> with event delivery. I'd like to pull it all together and make it >>> coherent on Windows, OS X and Unix. >>> >>> Its really great that Pharo has integrated the HostMenus stuff - I >>> think it would be cool to do HostWindows too. Once you eliminate >>> having to emulate the look of the windows - most widget sets look >>> pretty similar and I think morphic widgets inside of real windows >>> would keep things from looking too weird while preserving the >>> benefits of having our widgets in Smalltalk. >>> >>> Given Pharo's "take no prisoners" attitude, I think getting host >>> windows working would allow a lot of really ugly code in >>> PasteUpMorph and HandMorph to just go away. Event delivery in >>> Morphic is just totally incomprehensible and I'm finding it is >>> broken when a second window is introduced as the mouse coordinates >>> seem to be delivered window relative. Its also really hard to work >>> on because I keep junking images by making changes that wreck the >>> UI. >>> >>> -Todd Blanchard >>> >> >> -- >> = >> = >> = >> = >> = >> = >> ===================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >> squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> = >> = >> = >> = >> = >> = >> ===================================================================== >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 18, 2009

Re: [Pharo-project] ORM for Pharo

by Esteban A. Maringolo

SqueakSave seems to bee pretty attractive, does it work in Pharo? Shouldn't it be PharoSave? :) Regards! Esteban A. Maringolo

Aug. 18, 2009

Re: [Pharo-project] ORM for Pharo -- Â½ OFF

by Esteban A. Maringolo

I'm arriving late to this discussion... I think that having a good ORM solution is important to enterprise applications... and not only enterprise but if you have tables with LOTS of rows, you need to map them to objects. Don't start talking about Gemstone, I like, it's rock solid, but sometimes, most of the times I would say, it's out of the discussion. Even with objects mapped to tables, you can do real good object programming. I don't want to see another isolated Smalltalk again, the more able you are to interconnect with the external world, the better. Regards, Esteban A. Maringolo 2009/8/16 Carlos Crosetti <carlos(a)mostar.com.ar>: > IMHO Pharo must stick to the roadmap milestones, keeping clear boundaries on > what goes in and out - I value that some people are acting as gatekeepers. > > Then a second community, those who develop frameworks that run on top of > Pharo, like the authors of frameworks of Seaside, Glorp,,SqueakDBX (to name > a few comingÂ from the top of my head)Â may probably try to ensure their > frameworks progresses aligned with the Pharo releases, demanding a rrobust > and performant Smalltalk system Â impementattion. > > Now, to boost Pharo adoption, beyod smalltalkers, and to capture the > attention of new people, probably not familiar with the language, > technology, style, the system itself, the paradigm, and (why not) the > culture,, a new foundation of spin-off should address the level of effort to > envision and manufacture... > #1 a rich set of widgets and > #2 recipes showing how to combine them to produce high-impact realtime > client GUIs > > As an example I mention what > - Swing, AWT and SWT is for Java, > - Tk is for Tcl, > - GTK+ to C++, (and lots of....) > - UIPaainter to VisualWorks, > > and so on..:) > > -----Mensaje original----- > De: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de > csrabak(a)bol.com.br > Enviado el: SÃ¡bado, 15 de Agosto de 2009 01:04 p.m. > Para: Pharo-project(a)lists.gforge.inria.fr > Asunto: Re: [Pharo-project] ORM for Pharo -- Â½ OFF > > Mariano, > > I can understand the goal be Pharo idea and goal as you post.Â What I'm > trying to bring (and hopefully add to this discussion) is how can we arrive > there. > > We need to narrow down the definition of "enterprise application" and see > where Pharo can start to thrive.Â No all encompassing approach would work as > notwithstanding how poweful and complete Pharo could become it will not be > anytime soon. > > The notion that Pharo be not assotiated per se to any UI it is a strong (and > I vote to maintain it) design goal but in order to push forward Pharo > together with robust and clean implementation we'll need a lot of energy and > effort to produce enough educational materials like tutorial, manuals, etc., > it will be confusing all the time have an example that do not work in > another minor variation of UI (to stay in a single topic). > > So I return to the point: we need to have more clear goals on what > particular realm we see Pharo as feasible for enterprise development and be > able to enumerate what are the advantages of Pharo versus the other > approaches. > > Hope it is more explicit now ;-) > > Em 14/08/2009 20:42, Mariano Martinez Peck < marianopeck(a)gmail.com > > escreveu: > > > 2009/8/14 <csrabak(a)bol.com.br> >> >> Mariano, >> >> I agree (and I myself have been on the Research side getting answers >> similar to those ones) in fact I'll add another item to your list: >> >> -- They have an "architectural steering committee" that dictates use of >> some RDBS >> >> I've seen this even requiring some ERP used different database engine thas >> suggested by supplier. . . >> >> So if we want to compete with enterprise applications we need to get into >> some Enterprise: >> >> We're still thinkering with printing in Pharo (and this is PITA when >> attempting to be platform agnostic), so no Report Generator still, no matter >> how well you connect to a RDBS, any slightly above trivial example CRUD >> application will need this support. >> >> Our present set of widgets is sleek but still not as comprehensive as the >> other competing approaches, and we still have not created enough baseline to >> have an "echo system" so third parties can augment them as it happens now >> with Java, .Net and happened (and still as legacy updates) in Delphi and VB. >> >> So if the goal is to reach those enterprise trench we have to find some >> company that would profit of having [Pharo] Smalltalk as a primary language >> to customize or augment their system, as today (say as sake of example, SAP >> has ABAP but with Netweaver is going Java, and they competitors similar >> path). >> >> Let's think about this: historically some (comercial) Smalltalks allowed >> via OLE (a.k.a. COM, etc.) to access Microsoft Office features and do things >> similar as VB (in fact even Tcl and Python allow that), but what is the >> "productivity" of programmer that finds a tutorial or an example in VB and >> has to "translate" it to Smalltalk? >> >> As today can we enumerate what would be an advantage of doing something in >> Pharo instead of some "mainstream" language just to do some GUI painting >> CRUD application? > > I don't know if I understand you. The idea and goal behind Pharo is to have > the open, free, clean and robust smalltalk that we were missing for years > for commercial applications. At least that's my idea of Pharo. It must be a > platform and a base where you can create tools in it and with both of them > create real applications. > > In my opinion Pharo shouldn't be associated with a particular UI (web or > desktop) neither to a persistence strategy. Pharo must be the base of all > that. So then you can have differents alternatives: For UI's you can have > PolyMorph and the UI Builder. For Web you can have Seaside and Aida/Web. But > pharo is not coupled with any of them. You will then choose the solutions > that best feets your needs. > > In summary, I would love to use Pharo as platform to build enterprise and > commercial applications. No matter how do I persist or display my objects. > > Best, > > Mariano > > >> >> >> again my 0.01999.... >> >> Regards, >> >> -- >> >> Cesar Rabak >> >> >> >> Em 14/08/2009 16:57, Mariano Martinez Peck < marianopeck(a)gmail.com > >> escreveu: >> >> >> 2009/8/14 <csrabak(a)bol.com.br> >>> >>> Esteban, >>> >>> I'm comenting this on philosophical grounds. >>> >>> I understand the efforts to have SqueakDBX and other ORM in Pharo are >>> motivated by Seaside and other "production" initiatives so, again, my food >>> for thought is more an intellectual contribution which I see as useful for >>> Pharo as project: >>> >>> I don't see Pharo any time soonÂ® having all the toolset to be able to >>> compete in the CRUDÂ¹ realm with more streamlined tools and besides, not >>> matter how much theoretical work has been done on ORM, the "impedance >>> mismatch" is still there, >> >> Hi! I am agree with you about the "impedance mismatch". I think that if I >> am free to choose a persistence strategy I would use an OODB. However, if we >> are talking about real enterprise application (not a simple webpage) being >> able to choose the persistence strategy is practically impossible. We did a >> survey last year and the results were that most of the times you cannot >> choose. Of course, the client has a lot of reasons: >> >> - The client already has a RDBMS >> - They had paid for it and have the license (sometimes) >> - They want a company's support. The only company here is Gemstone. >> - RDBMS has history and it is an standard >> - They have knowledge about it >> - Interaction with other system (even legazy systems) >> - They are afraid of using another persistence strategy >> - They want to use SQL >> - They have DBAs >> - The persistence is difficult to negotiate >> >> So. In my opinion, if Pharo wants to be used really as a platform for >> enterprise applications (competing to java, .NET, etc), it must have a good >> relational solution. Of course, when you are able to choose, you can go for >> another approach like OODB. >> >> Best, >> >> Mariano >>> >>> a recent and practicall account of this (for Squeak) can be found in >>> >>> http://onsmalltalk.com/simple-image-based-persistence-in-squeak >>> >>> also, AIDA/Web has been able to run only storing thing in the image! See >>> >>> >>> http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/d3b… >>> >>> Since we'll increase the educational efforts to spread Pharo, I think >>> that as technology we should to recover a bit of Smalltalk technology and be >>> first more Object Oriented and then see if ORM still is so needed. >>> >>> my 0.0199999.... >>> >>> -- >>> >>> Cesar Rabak >>> >>> [1] http://en.wikipedia.org/wiki/Create,_read,_update_and_delete >>> Em 14/08/2009 16:14, Esteban A. Maringolo < emaringolo(a)gmail.com > >>> escreveu: >>> >>> My prototype is getting less proto, and I found out it doesn't have >>> complex relations, and the system is going to perform faster if I have >>> tables for most of it. >>> >>> What are the choices I have for doing ORM in Pharo? >>> >>> Â¿Does GLORP work? Â¿Any other options? >>> I don't have a strong preference for the RDBMS engine, it can be >>> anything (free), being it MySQL, PostgreSQL or Sql Server Express. >>> >>> Best regards, >>> >>> Esteban A. Maringolo >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 18, 2009

Re: [Pharo-project] [lewis@mail.msen.com: Re: [Vm-dev] Fwd: Could not load VMMaker in 10315]

by Igor Stasenko

2009/8/18 David T. Lewis <lewis(a)mail.msen.com>: > FYI. This problem was originally reported on the Pharo list earlier this > year. The fix is now in VMMaker on SqueakSource. > Great! Thank you David. > ----- Forwarded message from "David T. Lewis" <lewis(a)mail.msen.com> ----- > > Date: Tue, 18 Aug 2009 08:05:22 -0400 > From: "David T. Lewis" <lewis(a)mail.msen.com> > To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > Subject: Re: [Vm-dev] Fwd: [Pharo-project] Could not load VMMaker in 10315 > > > VMMaker (from SqueakSource) can now be loaded into closure-enabled images. > > I was able to remove a couple of temp variables from the GeniePlugin > primitive without affecting the logic. This was discussed on several > lists back in May. > > The fix is in VMMaker-dtl.135 on SqueakSource, and is documented in > Mantis http://bugs.squeak.org/view.php?id=7384. > > Dave > > On Mon, May 25, 2009 at 10:37:15PM -0400, David T. Lewis wrote: >> >> On Mon, May 25, 2009 at 11:06:10AM -0700, Eliot Miranda wrote: >> > >> > On Mon, May 25, 2009 at 7:40 AM, David T. Lewis <lewis(a)mail.msen.com> wrote: >> > >> > > >> > > On Sun, May 24, 2009 at 01:44:52PM -0700, Eliot Miranda wrote: >> > > > >> > > > 3. refactor the GeniePlugin method into an outer args parser and an inner >> > > > engine method and solve the problem. Â Since VMMaker will inline anyway >> > > this >> > > > shouldn't make performance worse. Â I haven't done this because I'm not >> > > the >> > > > author and it is quite a complex method. >> > > >> > > This sounds like the right thing to do, regardless of what may change >> > > in the compiler(s). >> > >> > >> > +1 >> > >> >> Well unfortunately the refactoring turns out to be easier said than done. >> At least it was easier for me to say it than it was for me to do it. >> >> I made a naive attempt to split the primitive into smaller methods, but this >> just ended up trading off too many things on the stack for too many arguments >> in an argument list. >> >> The method temp variables could be changed to be instance variables. This >> would probably work fine for any current VMs (not sure about Hydra), but >> it does not pass the smell test IMO. >> >> I suspect that Nathaniel Schaerli knew what he was doing when he wrote >> this primitive, and I most certainly do not, so I don't expect that I will >> make much further progress on this front. >> >> Dave > > ----- End forwarded message ----- > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Aug. 18, 2009