Re: [Pharo-project] UDP Listener example?
Thanks, I found this but it pretty well ignores UDP other than mentioning it exists. On Feb 6, 2012, at 1:38 PM, jannik.laval wrote: > Hi Todd, > > The socket chapter in writing progress could help you: > https://gforge.inria.fr/scm/viewvc.php/*checkout*/PharoByExampleTwo-Eng/Sockets/Sockets.pdf?root=pharobooks > I do not remember if the receiveData method is blocking. If not, you should > wait til data arrives. > > Cheers, > Jannik > > On Feb 6, 2012, at 22:22 , Eagle Offshore wrote: > >> I'm trying to build a display for some instruments that multicast readings >> using UDP. I started out using CocoaAsyncSocket on Mac >> (https://github.com/robbiehanson/CocoaAsyncSocket) and I have to say it has >> a really wonderful api - would be worth cloning it. >> >> However, want to do the same thing in Pharo so I have typed this little >> snippet into the workspace: >> >> [| socket | >> socket := Socket newUDP. >> 10 timesRepeat: [| s | >> s := String new. >> socket receiveDataInto: s fromHost: (NetNameResolver >> addressFromString:'255.255.255.255' ) port: 4848. >> Transcript show: s.]] fork >> >> and it doesn't seem to do anything. >> >> What have I missed? Pharo 1.3 stable on SnowLeopard BTW. >> >> Thanks, >> -Todd Blanchard >> > > --- > Jannik Laval > >
[Pharo-project] UDP Listener example?
I'm trying to build a display for some instruments that multicast readings using UDP. I started out using CocoaAsyncSocket on Mac (https://github.com/robbiehanson/CocoaAsyncSocket) and I have to say it has a really wonderful api - would be worth cloning it. However, want to do the same thing in Pharo so I have typed this little snippet into the workspace: [| socket | socket := Socket newUDP. 10 timesRepeat: [| s | s := String new. socket receiveDataInto: s fromHost: (NetNameResolver addressFromString:'255.255.255.255' ) port: 4848. Transcript show: s.]] fork and it doesn't seem to do anything. What have I missed? Pharo 1.3 stable on SnowLeopard BTW. Thanks, -Todd Blanchard
Re: [Pharo-project] RoarVM - Pharo and Squeak on Multicore
So how does it spread out the workload? Where can I read more about how it handles concurrency and race conditions? On Nov 3, 2010, at 1:10 AM, Torsten Bergmann wrote: > Read more: > > http://astares.blogspot.com/2010/11/roarvm-pharo-and-squeak-on-multicore.html > -- > GRATIS! Movie-FLAT mit über 300 Videos. > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome >
Re: [Pharo-project] Scamper revival
Squeak - Pharo - same thing. I didn't say it would wipe out Smalltalk's place in the world - I said it will fulfill its mission - which is one more level of marginalization. At this point, it is easier to write a portable desktop app in a webkit based browser than it is to write one in Pharo. On Mar 1, 2010, at 4:20 AM, Schwab,Wilhelm K wrote: > First, I'm not using Squeak. Second, this is not the first time I've heard > that xyz was going to wipe out Smalltalk's place in the world, and I doubt it > will be the last. > > Bill > > > -Original Message- > From: Eagle Offshore [mailto:eagleoffsh...@mac.com] > Sent: Monday, March 01, 2010 12:09 AM > To: Schwab,Wilhelm K > Subject: Re: [Pharo-project] Scamper revival > > Then what are you doing with Squeak? :-) The browsers support offline > development with local databases in HTML 5. This is here, now. They will > replace squeak's mission in about another three years. Probably less. > > On Feb 28, 2010, at 12:04 PM, Schwab,Wilhelm K wrote: > >> There is the further concern about the browser. It wastes screen space >> (which is at a premium) and adds weight and distracting functionality. >> There is something to be said for the a fat client app that does what it >> needs to do and nothing else. >> >> >> >> >> -Original Message- >> From: pharo-project-boun...@lists.gforge.inria.fr >> [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of >> Eagle Offshore >> Sent: Sunday, February 28, 2010 2:23 PM >> To: Pharo-project@lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Scamper revival >> >> I wouldn't be so sure. >> >> http://html5demos.com/ >> http://jqtouch.com/ >> >> On Feb 27, 2010, at 4:41 PM, Schwab,Wilhelm K wrote: >> >>> there is no way in hell that HTML+CSS+JavaScript is going to keep up >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Scamper revival
I wouldn't be so sure. http://html5demos.com/ http://jqtouch.com/ On Feb 27, 2010, at 4:41 PM, Schwab,Wilhelm K wrote: > there is no way in hell that HTML+CSS+JavaScript is going to keep up ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Scamper revival
Quick thought: WebKit plugin with Javascript language binding. http://webkit.org/projects/javascript/index.html Consider the kind of system you could build with html 5 rendered UI. Interesting project: http://phonegap.com Sadly, I have zero time to work on things outside of paying work these days. On Feb 27, 2010, at 7:33 AM, Germán Arduino wrote: > I agree with these comments (don't know if the way to go is Polymorph being > that I don't know it deeper) but as I also think that Magritte is a BIG help > to write almost any sort of applications. > > I we could have a better (more productive) way of write desktop UIs then we > can take over the win-linux.mac market :) I would try myself with my > PasswordsPro application (currently in Dolphin). It would be nice to me port > PasswordsPro to Pharo and sell it as a real desktop app (native in any > operating system) and reuse the same model to have it on web also. > > Having a only one model, with UI in desktop and web will be really awesome, > even when a lot of people may claim that is possible today, I'm not really > convinced with complex applications. > > Cheers. > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo changing the game
It is not a code problem. It is a social/political problem. On Feb 13, 2010, at 1:52 AM, Stéphane Ducasse wrote: > Send code and it will be fixed in one hour. > > Stef > >> I think the really tragic thing is that nothing in Smalltalk remains stable. >> >> It would seem to me that in a language that has been around thirty years or >> so that core data types like numbers, dates, times, and (hopefully, although >> adoption of unicode was disruptive) strings would be the same across all the >> dialects. >> >> By now, there should be some chunks of the system that we can deem fully >> mature and then learn to LEAVE ALONE. >> >> The 16rff issue is a fine example of an absolutely stupid incompatibility. >> >> Just my $.04 >> >> -Todd Blanchard >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo changing the game
I think the really tragic thing is that nothing in Smalltalk remains stable. It would seem to me that in a language that has been around thirty years or so that core data types like numbers, dates, times, and (hopefully, although adoption of unicode was disruptive) strings would be the same across all the dialects. By now, there should be some chunks of the system that we can deem fully mature and then learn to LEAVE ALONE. The 16rff issue is a fine example of an absolutely stupid incompatibility. Just my $.04 -Todd Blanchard ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Native Windows
I've gotten a bit further but I'm finding it maddening in that quite often the whole thing will freeze for no apparent reason and with no clue as to what it is doing. I've just been working with the transcript. It launches in another window, it resizes properly, you can type into it, select all and delete, etc However I cannot get it to update in the background nicely (which is kind of the point for Transcript) although it updates just fine when in the foreground. I've implemented enough Morph protocol in DisplayHostWindow to allow it to serve as the root morph (although it actually holds a single morph that it keeps the same size as its window). The key method seems to be invalidRect: damageRect from: aMorph self redrawInBounds: damageRect. self forceToScreen: damageRect which, if I implement it, works briefly and then goes slower and slower and eventually hangs. I tried using CachingMorph as the root morph - this results in fullBounds based infinite recursion. Somehow I think this is at the root of Morphic's painful inefficiency. I think the layout/damage management code is trying to do too much. I've put about 40 hours into trying to track this - I'm taking a little break before diving in again. My head is quite bruised from banging it on that wall. -Todd Blanchard On Aug 25, 2009, at 1:24 AM, Henrik Johansen wrote: Made a small experiment the other week of, sharing in case someone's interested. It renders an arbitrary SystemWindow in a ffenestri-window (on mac at least) in the simplest way I could think of at least. (not efficient (3MB or so per window), nor exactly pretty), but it makes for a nice demo imo, even though the window is unresponsible to input. Render update on resizing works, with a faux render loop instead of real window resize event response :) In theory you can do openInWorld on the same window, and manipulate that, but I wouldn't recommend it, as the faux loop in the workspace is in no way synchronized with World Drawing and you will get DNU's after awhile. Install the changesets from ftp.smalltalkconsulting.com/experimental/Ffenestri/ first, then the changeset in the attached zip. Doit'ing the workspace in the .rtf should then open a Hierarchy Browser on HierarchyBrowser, read comments there for more details :) Should work on any SystemWindow instance, though actually getting to an instance before it's opened can be surprisingly hard... Cheers, Henry On Aug 18, 2009, at 8:33 39PM, Eagle Offshore wrote: What is the "canonical" window class in Pharo? I see SystemWindow has been subclassed and there's a separate builder for the other window that is otherwise a copy of the default builder. Where was that going? On Aug 18, 2009, at 10:01 AM, Gary Chambers wrote: 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" To: Sent: Tuesday, August 18, 2009 4:11 PM Subject: Re: [Pharo-project] Native Windows 2009/8/18 Eagle Offshore : 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 : 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
[Pharo-project] ToolBuilder vs MorphicToolBuilder vs PSToolBuilder
What are the differences? It looks like most things are just using ToolBuilder right now - correct? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Native Windows
What is the "canonical" window class in Pharo? I see SystemWindow has been subclassed and there's a separate builder for the other window that is otherwise a copy of the default builder. Where was that going? On Aug 18, 2009, at 10:01 AM, Gary Chambers wrote: > 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" > To: > Sent: Tuesday, August 18, 2009 4:11 PM > Subject: Re: [Pharo-project] Native Windows > > >> 2009/8/18 Eagle Offshore : >>> 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 : >>>>> 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 >>>>
Re: [Pharo-project] Native Windows
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 : >> 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. McIntoshTwitter: >> squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> = >> = >> = >> = >> = >> = >> = >> >> >> >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@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@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Native Windows
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 On Aug 17, 2009, at 6:02 PM, John M McIntosh wrote: Well let me comment For years the squeak community complained about the fact there was just one window and morphic, and no way to offer native widgets or have more than one window. The folks providing funding for Sophie complained about this same fact too. So years ago, Tim and I spent a summer working out how to provide the multiple window support for Squeak aka Areithfa Ffenestri http://wiki.squeak.org/squeak/3862 It's quite simple, the HostWindowProxy proxy lets you manipulate the window and draw to it. The VM was changed so that Events *should* tag UI events with a window index number. EventSensor then brings up the events and hands them to who ever is interested. It's all fully explained on the web page. We built it on the macintosh first, with *pending* support for the other platforms. I'm sure Bert did a Linux variation. mmm I'm sure windowIndex 0 refers to the main squeak window btw. The original source code without complexity should sit in the ftp.smalltalkconsulting.com/experimental/Ffenestri/ changes sets Ffenestri-b-1 thru b-4 You should be able to load it into a Squeak image from Jan 2007, infact I rebuilt the change sets and tested them in a January 2007 image for a pending Squeak release let's see, oh yes the email for that is attached at the end. We alter event sensor, as you know that was all changed in Pharo It also alters Moprhic a bit so it understands windowIndex logic. Now about implementation, part of the problem is where does the events go and where does the drawing go. Lots of this is done in globals with no reference to the windowIndex. We had two implementations (a) We alter Project, when you enter project it then set the Display, so we could make a Project Window and drawing and mouse events would go to it, I'm not sure about todays version of Morphic but in the past you could have multiple Projects open, but only one would be active, then others would be *stopped* (b) We altered Tweak, Tweak at the time being the future vision of Morphic and UI on Squeak. Tweak actually built an environment and stuck the UI input queue and display information in an instance variable associated with the Tweak world. So it was *trivial* to hook up the host window proxy display logic and dispatch the events to the proper Tweak world. (c) I lie, I believe Michael Rueger built a subset of morphic (or something) that is Ffenestri aware, but I don't think it was ever published. Out of this, there was a dull thud as the folks wanting multiple host windows just failed to produce code using it. The powers that be that directed Sophie decided in fact one window was enough, so we never implemented things with multiple windows. The version of Tweak we were using in Sophie was grave-yarded. Maybe you could send me the details of your trail of MC loading since I don't recall an Process or Delay overrides. We had lots of that in Sophie via changes from Tweak/Qwaq to fix evil semaphore and process bugs plus Tweak did process priority escalation to solve event ordering/semaphore issues. On 17-Aug-09, at 3:05 PM, Eagle Offshore wrote: Well, I may have spoken too soon. Digging into the platform specific window proxies - I see proxies for MacOS 9, OS X, Win32, and Acorn???, but nothing for linux. OTOH, I find source code for a HostWindows plugin in the Unix VM source tree. Anybody with more knowledge of why we have a plugin without a proxy? -- = = = = = == John M. McInto
Re: [Pharo-project] Native Windows
Have a look here: http://wiki.squeak.org/squeak/3862 On Aug 17, 2009, at 5:25 PM, Carlos Crosetti wrote: > is there a preview or screenshots of this package? > > -Mensaje original- > De: pharo-project-boun...@lists.gforge.inria.fr > [mailto:pharo-project-boun...@lists.gforge.inria.fr]en nombre de Eagle > Offshore > Enviado el: Lunes, 17 de Agosto de 2009 06:17 p.m. > Para: Pharo-project@lists.gforge.inria.fr > Asunto: [Pharo-project] Native Windows > > > I spent the weekend trying to get Ffenestri working in Pharo. It was > astonishingly painful, not the least of which because they are stored > as half a dozen monticello archives and the MC tool merge tool > requires you to address each conflict individually and the main change > is that at lot of morphic methods now have comments and _ has been > replaced with :=. There must be a better way. > > Also, the files have a lot of patches to Delay and Process and really > scary stuff like that and I was under the impression that those things > had been reworked since and I didn't want to introduce any sort of > regression so I didn't load them and focused on just making the plugin > interface work and patching the event delivery code to deliver window > events to the host windows (things like activate, iconize, close...). > > Debugging would be made a lot easier if I could identify a hook that > would let me close the native window with the debugger launches, then > reopen it when it proceeds - but I haven't a clue how that code works. > > Anyhow, I have a native window that opens with a sketch morph in it > and it does pretty much what I expect. Because of the OS doing window > image caching and its own damage repair from an offscreen buffer - it > feels wicked fast and responsive compared to our emulated windows. I > would like to push on this and bid farewell to our MDI-like interface > of windows within a window and finally switch to native windows with a > top level morph in each. > > I have some very mixed feelings about this as the window theming work > that has been done is really top notch. Absolutely wonderful - and > yet I'd like to throw it all away and go with the OS windows because > they're about a zillion times faster and more responsive (my wicked > fast 2GHZ Macbook Pro has about a half second delay to drag a window - > seriously - why?). > > It works OK on the Mac OS X. I'd like to find a windows and linux > person who would also like to work on this. I have no idea if it > works on other platforms. I also have no idea how I'm going to > extract my changes and ship them. I've had to hack > HandMorph>>processEvents and lord knows what else in the quest to make > this fly. I suppose I could file out a change set? > > Anyhow - it sort-of works except I think I've exposed a bug in event > coordinate translation and I don't understand mouseFocus and > keyboardFocus - how is that suppose to work? Or does it anymore? > Perhaps the folks who worked on recent event tweaks could enlighten > me? > > -Todd Blanchard > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Internal Virus Database is out-of-date. > Checked by AVG. > Version: 7.5.560 / Virus Database: 269.21.6/1323 - Release Date: > 10/03/2008 > 11:07 a.m. > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Native Windows
Well, I may have spoken too soon. Digging into the platform specific window proxies - I see proxies for MacOS 9, OS X, Win32, and Acorn???, but nothing for linux. OTOH, I find source code for a HostWindows plugin in the Unix VM source tree. Anybody with more knowledge of why we have a plugin without a proxy? On Aug 17, 2009, at 2:48 PM, Schwab,Wilhelm K wrote: > Todd, > > Many thanks for working on this!!! I suppose I qualify as a Linux > person. Certainly I have interest in having it work well, and I'm > completely sick of Microsoft. I know what you mean about there > having to be a better way to do things. Just saving all of my > packages for loading into a new image leaves me wondering why > nothing else has been done, or perhaps just what I am missing. > > Agreed about Pinesoft's work on Polymorph; it's stunning. I am glad > to hear that you have gotten far enough along to be able to report a > speed boost. I do not necessarily assume that native is faster; > emulated widgets have their use too, especially in very large > numbers. So Polymorph might live on in grids for things like > spreasheets where a native widget per cell might not scale terribly > well. > > I have some ideas (not necessarily good ones) on how code should get > from one image to another; I have little to no idea how to do that > with MC though. On Dolphin, I built a tool called Migrate that > tries to soften the blow, and would be happy to contribute any parts > of it that would be of value. The basic features are to scan > packages for a suitable load order[*] and to write a script for > loading them into a new image. Of course, Dolphin packages > understand dependencies, which is very helpful. I also defined a > concept of safe and dangerous selectors, e.g. #safe, #dangerous, > which could be referenced from any method, and Migrate would file > them out and (conditionaly) into the new image. That allowed me to > preserve fixes that I made to the base system, and warned me before > applying the fixes to a new version. > > Seaside 2.9 defines a class called WADevelopment that helps with > saving packages. > > [*] Dolphin's package system is quite good, and improved over the > years to the point that load order was almost a non-concern, right > about the time I started getting it right, maybe. > > Bill > > > -Original Message- > From: pharo-project-boun...@lists.gforge.inria.fr > [mailto:pharo-project-boun...@lists.gforge.inria.fr > ] On Behalf Of Eagle Offshore > Sent: Monday, August 17, 2009 4:17 PM > To: Pharo-project@lists.gforge.inria.fr > Subject: [Pharo-project] Native Windows > > I spent the weekend trying to get Ffenestri working in Pharo. It was > astonishingly painful, not the least of which because they are > stored as half a dozen monticello archives and the MC tool merge > tool requires you to address each conflict individually and the main > change is that at lot of morphic methods now have comments and _ has > been > replaced with :=. There must be a better way. > > Also, the files have a lot of patches to Delay and Process and > really scary stuff like that and I was under the impression that > those things had been reworked since and I didn't want to introduce > any sort of regression so I didn't load them and focused on just > making the plugin interface work and patching the event delivery > code to deliver window events to the host windows (things like > activate, iconize, close...). > > Debugging would be made a lot easier if I could identify a hook that > would let me close the native window with the debugger launches, > then reopen it when it proceeds - but I haven't a clue how that code > works. > > Anyhow, I have a native window that opens with a sketch morph in it > and it does pretty much what I expect. Because of the OS doing > window image caching and its own damage repair from an offscreen > buffer - it feels wicked fast and responsive compared to our > emulated windows. I would like to push on this and bid farewell to > our MDI-like interface of windows within a window and finally switch > to native windows with a top level morph in each. > > I have some very mixed feelings about this as the window theming > work that has been done is really top notch. Absolutely wonderful - > and yet I'd like to throw it all away and go with the OS windows > because they're about a zillion times faster and more responsive (my > wicked fast 2GHZ Macbook Pro has about a half second delay to drag a > window - seriously - why?). > > It works OK on the Mac OS X. I'd like to find a
Re: [Pharo-project] Getting Javascript in Moose and/or Pharo
I will go you one better. I want to do a port of webkit basing it on the GTK one because that one has a C api and can run more or less identically on OSX, Windows, and linux. I want web content in Pharo and I don't want to maintain it - I'd rather we adopt it. Then, I want to explore bridging the DOM to smalltalk objects. I've been downloading and building this stuff all weekend. This is very preliminary - its taken all weekend to download all of the required libraries to build gtkwebkit on the mac. I also had the idea some time ago about building an entire UI on top of webkit using bridged smalltalk DOM. This would let you specify your widget layout as HTML/CSS but code in Smalltalk and provide a more or less portable but native UI. Apparently, I'm not the only one with this idea. http://www.advogato.org/article/981.html -Todd Blanchard On Aug 17, 2009, at 2:24 PM, Alexandre Bergel wrote: > Dear List > > Making Pharo interacting with Javascript has been the cup of tea of > the Seaside community. > I am wondering whether there has been an attempt to produce a parser > for Javascript within Pharo. > > We are interested in getting Javascript models within Moose. > > For now, it is likely what we will use the parser of Mozilla to > produce MSE files. > > Cheers, > Alexandre > > NB: Sorry for the cross-posting > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Native Windows
I spent the weekend trying to get Ffenestri working in Pharo. It was astonishingly painful, not the least of which because they are stored as half a dozen monticello archives and the MC tool merge tool requires you to address each conflict individually and the main change is that at lot of morphic methods now have comments and _ has been replaced with :=. There must be a better way. Also, the files have a lot of patches to Delay and Process and really scary stuff like that and I was under the impression that those things had been reworked since and I didn't want to introduce any sort of regression so I didn't load them and focused on just making the plugin interface work and patching the event delivery code to deliver window events to the host windows (things like activate, iconize, close...). Debugging would be made a lot easier if I could identify a hook that would let me close the native window with the debugger launches, then reopen it when it proceeds - but I haven't a clue how that code works. Anyhow, I have a native window that opens with a sketch morph in it and it does pretty much what I expect. Because of the OS doing window image caching and its own damage repair from an offscreen buffer - it feels wicked fast and responsive compared to our emulated windows. I would like to push on this and bid farewell to our MDI-like interface of windows within a window and finally switch to native windows with a top level morph in each. I have some very mixed feelings about this as the window theming work that has been done is really top notch. Absolutely wonderful - and yet I'd like to throw it all away and go with the OS windows because they're about a zillion times faster and more responsive (my wicked fast 2GHZ Macbook Pro has about a half second delay to drag a window - seriously - why?). It works OK on the Mac OS X. I'd like to find a windows and linux person who would also like to work on this. I have no idea if it works on other platforms. I also have no idea how I'm going to extract my changes and ship them. I've had to hack HandMorph>>processEvents and lord knows what else in the quest to make this fly. I suppose I could file out a change set? Anyhow - it sort-of works except I think I've exposed a bug in event coordinate translation and I don't understand mouseFocus and keyboardFocus - how is that suppose to work? Or does it anymore? Perhaps the folks who worked on recent event tweaks could enlighten me? -Todd Blanchard ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Squeak versus Pharo as application name
I think that the name has to come from the executable. The idea of Pharo is to have a Smalltalk that can be shipped. So if someone were to create an application and wanted a custom wrapped double clickable file with a name like - oh - Sophie.app - then it would adjust the menus appropriately. On Aug 16, 2009, at 11:37 PM, Stéphane Ducasse wrote: > The simplest for you and > > On Aug 17, 2009, at 2:25 AM, John M McIntosh wrote: > >> >> On 16-Aug-09, at 2:50 PM, Stéphane Ducasse wrote: >> >>> The point is that pharoers should implement the vision not pharo. >>> We have enough to do. The fact that pharo will succeed depends also >>> on >>> us as >>> a community nor just 5 guys doing an integration of fixes. >>> >>> Stef >> >> Ok let's talk about bug >> http://code.google.com/p/pharo/issues/detail?id=1068&q=quit&colspec=ID%20Type%20Status%20Summary%20Milestone >> >> Part of this is the *purge* of the string Squeak from the image, so >> Quit Squeak Vm doesn't fire the quit logic >> >> (a) I'd rather not have to build two VMs, one for Squeak and one for >> Pharo > > agree. Now does the event cleaning and other have no impact on the vm > level? > >> (b) Also I'd rather not have to answer is the Pharo VM different from >> the Squeak VM? > agree > >> (c) If you take the Squeak.app and rename it all to Pharo then >> someone >> has to manage that process and ensure the Pharo clone is cloned >> properly from the Squeak.app > > yes may be we could have a script for that > >> (d) if you have a Pharo.app the question then is where did it come >> from? > > **We** could have a script for transforming squeakvm into pharo vm > >> (e) I do agree having a Pharo app, then seeing quit Squeak VM is very >> confusing, therefore people should be able to change that to suit >> their needs. > > may be we should use platform and extend it to vm or system name >> >> So how would people like to see how this would work. >> >> This of course precludes any discussion of how the linux & windows >> versions behave and give textual feedback. >> >> >> -- >> = >> = >> = >> = >> = >> = >> = >> John M. McIntoshTwitter: >> squeaker68882 >> Corporate Smalltalk Consulting Ltd. http:// >> www.smalltalkconsulting.com >> = >> = >> = >> = >> = >> = >> = >> >> >> >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Squeak versus Pharo as application name
Why are the menus not being built from within the image/and/or the path/name of the executable? On Aug 16, 2009, at 5:25 PM, John M McIntosh wrote: > > On 16-Aug-09, at 2:50 PM, Stéphane Ducasse wrote: > >> The point is that pharoers should implement the vision not pharo. >> We have enough to do. The fact that pharo will succeed depends also >> on >> us as >> a community nor just 5 guys doing an integration of fixes. >> >> Stef > > Ok let's talk about bug > http://code.google.com/p/pharo/issues/detail?id=1068&q=quit&colspec=ID%20Type%20Status%20Summary%20Milestone > > Part of this is the *purge* of the string Squeak from the image, so > Quit Squeak Vm doesn't fire the quit logic > > (a) I'd rather not have to build two VMs, one for Squeak and one for > Pharo > (b) Also I'd rather not have to answer is the Pharo VM different from > the Squeak VM? > (c) If you take the Squeak.app and rename it all to Pharo then someone > has to manage that process and ensure the Pharo clone is cloned > properly from the Squeak.app > (d) if you have a Pharo.app the question then is where did it come > from? > (e) I do agree having a Pharo app, then seeing quit Squeak VM is very > confusing, therefore people should be able to change that to suit > their needs. > > So how would people like to see how this would work. > > This of course precludes any discussion of how the linux & windows > versions behave and give textual feedback. > > > -- > = > = > = > = > = > == > John M. McIntoshTwitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > == > > > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] question on browser buttons
Concur - just downloaded latest image because trying to update from 10391 image results in frozen UI. Also, I preferred the rounded windows and menus. On Aug 14, 2009, at 5:58 AM, Mariano Martinez Peck wrote: +1 On Fri, Aug 14, 2009 at 7:22 AM, Stéphane Ducasse > wrote: +1 On Aug 14, 2009, at 8:23 AM, Adrian Lienhard wrote: > +1 > > (They are like this in the latest Pharo image (not Pharo-core)). > > Adrian > > On Aug 14, 2009, at 01:29 , csra...@bol.com.br wrote: > >> I don't see these... which image version and which System Browser >> are you using? >> >> >> Em 13/08/2009 20:19, Michael Roberts < m...@mjr104.co.uk > escreveu: >> >> >> folks, just wondering what people think about the big 'blue' class >> browser buttons. Pharo is looking really nice, but i tend to prefer >> somewhat smaller, plainer buttons. e.g on the test runner, or the >> preference browser. the browser ones are twice as high! they just >> seem to stick out a bit. >> >> is it easy to switch off these blue buttons, or make all buttons >> consistent? >> >> thanks, >> Mike >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] New Pharo based on core 10413
I just downloaded the 1.0beta on the site and it immediately throws up a deprecation warning bout initialsPerSe - please use fullNamePerSe That makes a poor first impression. On Aug 9, 2009, at 10:48 AM, Damien Cassou wrote: > Please download and report problems: > > http://pharo-project.org/pharo-download > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] SWHTTPClient
Wasn't there a curl plugin? Or did it not get finished? -Todd Blanchard ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo Feature Roadmap Question
I have tried to get this running in Squeak on my own three or four times. I have had no luck with it. I love the idea in principle, but there are always errors I can't figure out when I try to make it work. -Todd Blanchard On Aug 11, 2009, at 12:27 AM, Stéphane Ducasse wrote: > if somebody helps yes :) > It should be in the list of items for 1.1 > > STef > > On Aug 11, 2009, at 6:10 AM, Eagle Offshore wrote: > >> It seems like Pharo 1.0 is crystallized already. >> >> Is native window support (Areithfa Ffenestri) in the near term plan? >> http://wiki.squeak.org/squeak/3862 >> >> -Todd Blanchard >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Pharo Feature Roadmap Question
It seems like Pharo 1.0 is crystallized already. Is native window support (Areithfa Ffenestri) in the near term plan? http://wiki.squeak.org/squeak/3862 -Todd Blanchard ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Polymorph depends on Sound
I was hoping with the snazzy new UI that we would get beyond web applications. :-) I agree that being able to offload it cleanly is good. On Jul 28, 2009, at 2:24 AM, Adrian Lienhard wrote: > I don't think it is a true core capability, considering that many if > not the majority of applications built with Pharo are web-based. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Polymorph depends on Sound
I understand wanting to limit dependencies and clean stuff up - but is there a particular reason why we don't think the basic ability to play sounds belongs in a base application development environment? Seems like a core capability and I worry about sound rotting if it doesn't live in the base image. -Todd Blanchard On Jul 28, 2009, at 12:34 AM, Adrian Lienhard wrote: > Hi Gary, > > In the Pharo project, there is a new version of Polymorph with these > changes. > > Cheers, > Adrian > > On Jul 27, 2009, at 11:54 , Gary Chambers wrote: > >> No problem. >> >> Regards, Gary >> >> - Original Message - >> From: "Adrian Lienhard" >> To: "Pharo Development" >> Sent: Saturday, July 25, 2009 10:21 AM >> Subject: [Pharo-project] Polymorph depends on Sound >> >> >>> Hi Gary, >>> >>> I'm working on removing the Sound package. Polymorph's SoundTheme >>> class has some methods that reference RestSound. >>> >>> For instance: >>> >>> windowRestoreDownSound >>> ^self sounds at: #windowRestoreDown ifAbsent: [RestSound dur: 0] >>> >>> >>> Could we change these methods, for example like this: >>> >>> windowRestoreDownSound >>> ^self sounds at: #windowRestoreDown ifAbsent: [self >>> defaultDefaultSound] >>> >>> and then >>> >>> defaultDefaultSound >>> ^ Beeper default >>> >>> Projects that use sound can then load the Sound package and define >>> their own SoundTheme. If this is OK with you I'll do these changes >>> in >>> Pharo and you can pick them up and merge them later. >>> >>> Cheers, >>> Adrian >>> ___ >>> http://www.adrian-lienhard.ch/ >>> >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Scamper
Nope, scamper is way out of date. I think the answer is to do a webkit plugin if we want web content in pharo. On Jul 21, 2009, at 8:13 AM, Brian Mason wrote: I’ve been trying to use scamper with no success. I’ve loaded the latest version from Monticello. Is there a later version? Is anyone supporting this? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Making GUI'S
Which I find funny because the one commercial grade swing app I did, I ended up building all that stuff because it was the only way I could see to get multiple views synced to the model without writing tons of glue code. Also, swing widgets don't like having null values as their data sources so the value models would keep them from throwing null pointer exceptions all the time. On Jun 20, 2009, at 4:25 AM, Steve Wirts wrote: I did a talk(attached) at OOPSLA several years ago to explain the benefits of ValueModels to java programmers, it was way over their heads. It's unfortunate as today I've yet to see anything in java that approaches the productivity they provide. 2009/6/20 Schwab,Wilhelm K Steve, Interesting that you mention value models. I just ran into a use for a ValueHolder, and discovered that Dolphin's #value, #value: protocol was not present. In fact ValueHolder>>value answers the receiver! I added an override to my Dolphin compatibility package. I exepect to add AspectValueAdapter and perhaps some converters as need arises. None of this takes away from Magritte; I share your interest in it and willingness to consider it as potentially powerful tool for GUI building. Bill From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr ] On Behalf Of Steve Wirts Sent: Friday, June 19, 2009 8:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Making GUI'S Value Models, TypeConverter library, SubCanvas support(super powerful idea here), etc... some really wonderful idioms long lost in OO guis. VisualWorks had some really nice frameworks that were discarded due to them being undervalued. I hope to eventually re-introduce some of these fun frameworks into pharo given my time constraints and interest from potential users. see http://c2.com/ppr/vmodels.html Magritte seems like it might be a superior alternative to VisualWorks ValueModels; I haven't explored it enough to really know yet. Pharo is the most exciting thing to come along for me in quite awhile! On Fri, Jun 19, 2009 at 4:42 PM, Stéphane Ducasse > wrote: > > I don't know what I am waiting for -- except more time -- because I > guess I should build such a thing. (Are there any Pharo/squeak coders > available for part-time consulting over the next year? ...At student > level pay I must add.) > > I too want a GUI builder. me too :) So may be we could have a kind of bounty system for pharo. Frankly we are rather full and we (the core) have not that much time for extensions but we would support any work in the direction of UIBuilder TestServer Package FileWrite-Rio kind of integration Better MC support (yes I should look at MC1.5) Better SUnit Better tools (for example like the newInspector) Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] How to run a "cron" job?
One way this is often done is to create a url that, when accessed, executes the periodic code you want and replies with a short status. Then create a crontab job on any host you like using curl to fetch that url on a schedule. Works on all web development environments and has the bonus that you can 'kick it' from any web browser if you want it done on demand. -Todd Blanchard On Jun 6, 2009, at 2:46 AM, Oscar Nierstrasz wrote: > > Hi folks, > > I need to run a periodic job in a Pier image. (Checking for new PDF > files and generating news items.) > > What is the recommended way to do this? > > Thanks in advance for any tips. > > - on > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FreeType?
I would be inclined to make it a 'latch preference'. It should do the scan on first startup on a new platform and then never again unless the user asked or the image is started on a new machine. How to tell if an image was last run on that machine or platform is left as an exercise for the implementor. :-) But that would be the most useful behavior. -Todd Blanchard On Jun 2, 2009, at 7:25 AM, Adrian Lienhard wrote: > > On Jun 2, 2009, at 16:13 , Gary Chambers wrote: > >> Depends whether you use the same image across multiple OSes... > > That is probably not that often the case, but if, what happens? Would > the selected fonts fall back to Accuny? > > I think we should disable UpdateFontsAtImageStartup by default to not > have to pay for the scanning on each image startup. People that > transfer images between different OSes have the possibility to enable > the preference. OK? > > Adrian > >> >> >> Regards, Gary >> >> - Original Message - >> From: Mariano Martinez Peck >> To: Pharo-project@lists.gforge.inria.fr >> Sent: Tuesday, June 02, 2009 2:21 PM >> Subject: Re: [Pharo-project] FreeType? >> >> >> >> >> >> On Tue, Jun 2, 2009 at 12:15 PM, Adrian Lienhard >> wrote: >> >> >> On Jun 2, 2009, at 15:00 , Steve Wirts wrote: >> >>> If the font reloading is taking longer than you would like for >>> startup, you >>> can disable it from >>> PreferencesBrowser>>FreeType>>UpdateFontsAtImageStartup >> >> >> Has anybody looked into whether the reloading is actually needed on >> each startup? Couldn't that be done only when the font browser is >> opened? >> >> That's exactly why I asked. It seems not necessary for me to be >> uploaded each time the image starts. How frequently your fonts >> change? >> >> IMHO this preference must be disable by default. >> >> Cheers, >> >> Mariano >> >> >> >> >> Adrian >> >> >>> >>> >>> On Sun, May 31, 2009 at 6:24 PM, Carlos Crosetti >>> wrote: >>> Hi, i loaded pharo, did "software update" and saved the image then quit. Loading again, I no longer see a file-not-found dialog, now I see a "FreeType" progress bar, showing and dissapearing twice... what is that? Regards, Carlos ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> >> >> -- >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Understanding of new Eliot Closures
I think copying the methods from BlockContext to BlockClosure is the correct course. -Todd Blanchard On May 18, 2009, at 4:56 PM, Mariano Martinez Peck wrote: > Hi! I am trying to make Glorp work on Pharo, and I having some > problems. In squeak I inspect [] and I see I have a BlockContext > object. In latest Pharo, I get a BlockClosure. I guess this is about > Eliot changes ? > > Now, Glorp has 5 methods extension in BlockContext. I saw > BlockContext and BlockClosure and they have no hierarchy in common. > So, if I want Glorp to work in squeak and pharo I must copy all that > 5 methods from BlockContext to BlockClosure? is there a better > solution ? I tried the first one and seems to work ok but I don't > know if it is correct. > > Thanks in advance, > > Mariano > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about libnui and licensing
Wow, I can't believe one of the more engaged developers who is current didn't engage on this (I am not actively working on Squeak or derivations due to financial commitments but I lurk with interest and wait for my next opportunity to engage). Sebastien, thanks for taking the interest. Smalltalk (and Squeak in particular) has long struggled with licensing issues. The system is completely open so it seems relatively pointless to encumber it with something like GPL. For your historical interest, the community's position on licensing (which is a little out of date as Pharo is going MIT style I think) is found at http://wiki.squeak.org/squeak/159. Perhaps someone else who knows more about the state of pharo could reply to this gentleman? -Todd Blanchard On Apr 26, 2009, at 4:05 AM, Sebastien Metrot wrote: > Hi, > > I'm the author of libnui which has been discussed here two days ago. > (i saw this list archive in the referer stats for libnui.net and was > curious ;-) ). > > Some people seemed interested in nui but had concerns about it's > licensing. I summarized our choice of license in this wiki page: > http://redmine.libnui.net/wiki/libnui/Licensing > . We're not particularly happy with the GPL but we found no real > other option that permitted to fulfill our requirements listed on the > page. > > As others have noted C++ is a very ugly language and recreating a > useable object model have been quite a chore. I'm curious about how we > could change nui to make it more friendly to other languages such as > smalltalk, knowing that C++ has always been a tad harder to > interoperate than, for example, C. > > Thanks in advance, > > Sébastien > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] For those who looking for 3D gui frameworks
I have many MOTU products and it seems many of them use it. http://www.libnui.net/ You can buy a commercial license: http://www.libnui.net/pages/licensing.php It may well be worth asking them if they'll do a special license given that Smalltalk is by nature mostly open source. Anyone wishing to do a commercial GUI app atop it for money would likely need to buy his own distribution license though. -Todd Blanchard On Apr 25, 2009, at 3:30 AM, Hilaire Fernandes wrote: Surprisingly the software bellow does not seem to be GPL but it seems to be using lib NUI. http://www.motu.com/products/software/machfive How is it possible? Oh may be a dual license scheme à la Troll Tech... Hilaire 2009/4/24 Michael Rueger Igor Stasenko wrote: > http://redmine.libnui.net/projects/show/libnui > Unfortunately it is GPL, not even LGPL. Michael ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://blog.ofset.org/hilaire ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo windows hanging ...
I assume c and d will get fixed (since doing animation from worker threads is pretty much the point). b - well of course you can't do UI work from FFI - you're not on the UI thread - unless you call performSelectorOnMainThread:... from there. a - I dunno - it seems like squeak's vm ought to do most work not on the UI thread except for UI things but the runtime models aren't exactly what I'd call fundamentally compatible since Cocoa wants to own the runloop and just call you back now and then via delegates or notifications. I have a Cocoa MIDI/CoreAudio AudioUnits host that makes heavy use of coreaudio (which ends up spawning a few dozen threads) but still animates pictures of keyboards, sound meters, etc in near real time and does it all by calling performSelectorOnMainThread:... and it all works like a charm so long as I remember to invoke the graphics update routines via performSelectorOnMainThread:. I would like to try out the new Cocoa bridge on a Mac at some point and see what can be done with it. -Todd Blanchard On Apr 22, 2009, at 10:30 PM, John M McIntosh wrote: > Ok, I have to comment since i'm up to my neck with alligators over > performSelectorOnMainThread: In fact just this evening 4 hours toasted > to document a bug with this call with Apple for tomorrow. > > (a) people don't realize with the carbon os-x vm we run on the Main > Thread and poll for os-x events that then get dispatch to the squeak > vm event handlers. > This leads to the interesting jerky non-responsive feedback you get > with the VM when you accidently kill the morphic polling loop, since > we aren't servicing > the UI event polling fast enough since we are using a fallback 1/2 > second ancient piece of code that in the past looked for the > interrupt key. > > (b) If you use the Unix os-x vm, that spins the squeak thread off as a > background task, now if you do UI related work via FFI then you die. > > (c) performSelectorOnMainThread: has lots of interesting bugs on the > iPhone, especially if you try to do view animation with it. > > (d) the iphone vm runs as a background thread, but deadlocks with > UIWebView between it and the main thread, are interesting, all > solvable, but interesting. Fortunately in the future we can migrate > back to (a) on the iPhone. > > (e) if you run on the Main Thread then you need something to handle > event callbacks from the UI when you call the UI to service a UI > event. Fortunately this has been worked out and is easier than (d) > > Frankly (a), (b), (c) and did I mention (d) are serious complications > I could do without. > > On 22-Apr-09, at 9:17 PM, Eagle Offshore wrote: > >> >> On Apr 22, 2009, at 11:38 AM, Igor Stasenko wrote: >> >>> But this is not the only UI framework which hates the concurrency - >>> take a look at "groundbreaking" Mac OS :) >> >> yes, but they have a nice mechanism for dealing with this when a >> worker thread wants to update the UI >> >> - (void)performSelectorOnMainThread:(SEL)aSelector withObject: >> (id)arg waitUntilDone:(BOOL)wait; >> >> Is there a Squeak equivalent for getting something invoked on the >> main UI thread? >> >> -Todd Blanchard >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > = > = > = > = > = > == > John M. McIntosh > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > == > > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo windows hanging ...
On Apr 22, 2009, at 11:38 AM, Igor Stasenko wrote: But this is not the only UI framework which hates the concurrency - take a look at "groundbreaking" Mac OS :) yes, but they have a nice mechanism for dealing with this when a worker thread wants to update the UI - (void)performSelectorOnMainThread:(SEL)aSelector withObject:(id)arg waitUntilDone:(BOOL)wait; Is there a Squeak equivalent for getting something invoked on the main UI thread? -Todd Blanchard ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
