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

Re: [Pharo-project] Is the plugin JoystickTabletPlugin of the CogVM package working?

by Eliot Miranda

Hi Carla, On Thu, Dec 13, 2012 at 7:15 AM, Carla F. Griggio <carla.griggio(a)gmail.com>wrote: > Hello! > Does anybody know if the JoystickTabletPlugin is actually working for > Pharo? I'm trying to use it with CogVM with no success :( I see > in InputEventHandler that there is support for pen tablets using this > plugin but I can't manage to make it work. As it comes in the CogVM package > I assume that somebody put it there because it works, but I keep getting > "PrimitiveFailed" error messages wether I have a tablet connected or not. > > The external plugins of the CogVM are supposed to work without me doing > anything? Just executing the VM? Or do I have to activate them somehow? > > Sorry for keep bothering with this :$ And thanks! > the Qwaq VM, which became the Cog fork disabled the joystick plugin. We can try and ressurect it but I'm not sure what is involved. What platform are you on? -- best, Eliot

Dec. 14, 2012

Re: [Pharo-project] About (backwards) Compatibility

by Chris Muller

> - the consensus is that FileSystem is a nice API > - the consensus is that FileDirectory is/was ugly Hence, you echo my original statement from the other thread. I wrote: >> ... While someone in the Pharo >> community said FileSystem over FileDirectory is "huge", I see it as an >> incremental API change, and close to being a matter of preference. > And you don't want to switch to it ? > Or you want to keep the old API and not force the switch on users ? Both. Because, while FileSystem is a cleaner design, the question posed was whether it is _worth_ breaking so many legacy packages and the promise of O.T. for "a nice API". That's when dramatic attempts to intensify the contrast between the two came out but with no concrete examples we arrived full-circle back to the original question. An acceptable compromise for me for putting it Squeak would be a FileDirectory wrapper that can pass its own test suite, which is precisely what Pharo did!

Dec. 14, 2012

Re: [Pharo-project] About (backwards) Compatibility

by H. Hirzel

On 12/14/12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 14 Dec 2012, at 17:55, Chris Muller <asqueaker(a)gmail.com> wrote: > >> I'm tired of talking about this but I just can't let this go.. I >> don't know if its just romantic, starry-eyed mountain climbers or >> intentional false-propaganda but... confusion reigns here! :) This >> example is bunk. > > Please, this is so silly: > > - the consensus is that FileSystem is a nice API > - the consensus is that FileDirectory is/was ugly > > And you don't want to switch to it ? > Or you want to keep the old API and not force the switch on users ? > > BTW: it is a done deal. The "deal" is done in the sense that Pharo 2.0 only uses FileSystem. This is the platform developer point of view. Sven, please take note that the deal is not done from the 'User land point' of view. Just recently Pharo 2.0 has gone from alpha to beta. Not to mention the porting status of the packages which build on it. So it is good to have alternatives as Igor points out -- Squeak, Cuis and earlier versions of Pharo. --Hannes > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > >

Dec. 14, 2012

Re: [Pharo-project] About (backwards) Compatibility

by H. Hirzel

On 12/14/12, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Chris Muller-3 wrote >> I don't know if its just romantic, starry-eyed mountain climbers or >> intentional false-propaganda > > Or both! ;) > > > Chris Muller-3 wrote >> This example is bunk > > Well, you're partly right - the clean version is not due totally to FS. The difference is file := FileDirectory directoryEntryFor: aString. "FileDirectory" as opposed to file := aString asFileName. "FileSystem" As Chris points out, the difference is minimal. Sean, it looks like you need better examples to show how you perceive the benefits of the FileSystem design > You'd be more right if human beings were rational beings. But we're not, > we're driven by emotion. I /feel/ bad when I look at FD, because I find it > ugly and confusing. Yes, FileDirectory has it's limitations. Many years ago I wrote a layer to deal with directory navigation for my own projects. As Marcus D. points out it is good that people have an OO abstraction to deal with directories and files. It saves time for beginners and new projects. In Squeak the discussion goes the way that FileDirectory should become a loadable package after FileSystem has been integrated in version 4.5. That way images with packages which require FileDirectory may still be built. --Hannes > Therefore, I would be reluctant to refactor that code > and it probably would still be in the state it is. But I was excited to > have > well-factored, intuitive FS objects to work with, which boiled into me > searching the system for ugly code to clean. That example was a quote from > a > previous post in my excitement after cleaning and making the system better. > Beauty and simplicity reverberates out well beyond the initial objects... > that's good enough for me. > > Sean

Dec. 14, 2012

Re: [Pharo-project] About (backwards) Compatibility

by Sven Van Caekenberghe

On 14 Dec 2012, at 17:55, Chris Muller <asqueaker(a)gmail.com> wrote: > I'm tired of talking about this but I just can't let this go.. I > don't know if its just romantic, starry-eyed mountain climbers or > intentional false-propaganda but... confusion reigns here! :) This > example is bunk. Please, this is so silly: - the consensus is that FileSystem is a nice API - the consensus is that FileDirectory is/was ugly And you don't want to switch to it ? Or you want to keep the old API and not force the switch on users ? BTW: it is a done deal. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 14, 2012

Re: [Pharo-project] Fwd: Lua scripting with nativeboost?

by ClÃ©ment Bera

Several months ago I made a prototype of a small game in amber. (To play my prototype, download it, run index.html and click Multiplayer>beta fight. The source is here : https://github.com/clementbera/easnoth:. It uses Jquery.getJSON() so it might not work on some web browsers/computers) I asked several smalltalkers why there was no game in Smalltalk. Most of them answered me it was because Smalltalk is too slow to run video game. It may be because of the GC as Lawson English said. If you want to do a game that requires a lot of performance (for example realtime + 3d), you should care. But if you want to do a small game, as the games we can find on smartphone or on website like armor games it is enough. I don't think that running a Lua script through native Boost is a good idea. It will work, but will be slower than pure Smalltalk. But I'm not a pro :) 2012/12/14 Frank Shearar <frank.shearar(a)gmail.com> > On 14 December 2012 20:26, Lawson English <lenglish5(a)cox.net> wrote: > > On 12/13/12 1:58 AM, Igor Stasenko wrote: > >> > >> On 13 December 2012 09:54, dimitris chloupis <thekilon(a)yahoo.co.uk> > wrote: > >>> > >>> I was ready to disagree , but you do make a valid point. > >>> > >>> Also going down the pharo route you dont offer games only a better > >>> language > >>> but also a development enviroment and that is a double win. I am > suprised > >>> that pharo is not used heavily for games. > >>> > >>> And no I dont believe sandbox is the reason. Afterall python is very > >>> popular > >>> with games too and has no sandbox. > >> > >> indeed, its all about marketing and having 'killer app', and then you > >> wont notice how eagerly new > >> people will jump into bandwagon. > >> > >> > > > > until certain issues with garbage collection are fixed, there will be no > > playable realtime games on any of the OSS Smalltalks. > > Details please! Does the time taken to GC vary too wildly, for example? > > frank > > > L > > > > -- > > Squeak from the very start (introduction to Squeak and Pharo Smalltalk > for > > the (almost) complete and compleate beginner). > > > https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all > > > > "Debugging is twice as hard as writing the code in the first place. > > Therefore, if you write the code as cleverly as possible, you are, by > > definition, not smart enough to debug it." - Brian Kernighan > > > > > >

Dec. 14, 2012

Re: [Pharo-project] Fwd: Lua scripting with nativeboost?

by Frank Shearar

On 14 December 2012 20:26, Lawson English <lenglish5(a)cox.net> wrote: > On 12/13/12 1:58 AM, Igor Stasenko wrote: >> >> On 13 December 2012 09:54, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: >>> >>> I was ready to disagree , but you do make a valid point. >>> >>> Also going down the pharo route you dont offer games only a better >>> language >>> but also a development enviroment and that is a double win. I am suprised >>> that pharo is not used heavily for games. >>> >>> And no I dont believe sandbox is the reason. Afterall python is very >>> popular >>> with games too and has no sandbox. >> >> indeed, its all about marketing and having 'killer app', and then you >> wont notice how eagerly new >> people will jump into bandwagon. >> >> > > until certain issues with garbage collection are fixed, there will be no > playable realtime games on any of the OSS Smalltalks. Details please! Does the time taken to GC vary too wildly, for example? frank > L > > -- > Squeak from the very start (introduction to Squeak and Pharo Smalltalk for > the (almost) complete and compleate beginner). > https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all > > "Debugging is twice as hard as writing the code in the first place. > Therefore, if you write the code as cleverly as possible, you are, by > definition, not smart enough to debug it." - Brian Kernighan > >

Dec. 14, 2012

Re: [Pharo-project] Fwd: Lua scripting with nativeboost?

by Lawson English

On 12/13/12 1:58 AM, Igor Stasenko wrote: > On 13 December 2012 09:54, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: >> I was ready to disagree , but you do make a valid point. >> >> Also going down the pharo route you dont offer games only a better language >> but also a development enviroment and that is a double win. I am suprised >> that pharo is not used heavily for games. >> >> And no I dont believe sandbox is the reason. Afterall python is very popular >> with games too and has no sandbox. > indeed, its all about marketing and having 'killer app', and then you > wont notice how eagerly new > people will jump into bandwagon. > > until certain issues with garbage collection are fixed, there will be no playable realtime games on any of the OSS Smalltalks. L -- Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner). https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian Kernighan

Dec. 14, 2012

Re: [Pharo-project] About (backwards) Compatibility

by Sean P. DeNigris

Chris Muller-3 wrote > I don't know if its just romantic, starry-eyed mountain climbers or > intentional false-propaganda Or both! ;) Chris Muller-3 wrote > This example is bunk Well, you're partly right - the clean version is not due totally to FS. You'd be more right if human beings were rational beings. But we're not, we're driven by emotion. I /feel/ bad when I look at FD, because I find it ugly and confusing. Therefore, I would be reluctant to refactor that code and it probably would still be in the state it is. But I was excited to have well-factored, intuitive FS objects to work with, which boiled into me searching the system for ugly code to clean. That example was a quote from a previous post in my excitement after cleaning and making the system better. Beauty and simplicity reverberates out well beyond the initial objects... that's good enough for me. Sean -- View this message in context: http://forum.world.st/About-backwards-Compatibility-tp4658784p4659295.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 14, 2012

[Pharo-project] NB Types and C Types

by Jimmie Houchin

Hello, In my app using NB and have a few questions on types. In one function I have an size_t *arg for an argument. Is NBUInt64 proper for this argument? I also have a DATE which uses OLE Automation date format which is described as: IO2GRequestFactory.fillMarketDataSnapshotRequestTime """ An OLE Automation date is implemented as a floating-point number whose integral component is the number of days before or after midnight, 30 December 1899, and whose fractional component represents the time on that day divided by 24. """ Would NBUInt64 be best or is NBUInt32 a better fit? I haven't seen a method for this particular date epoch, but I can easily write the method to handle conversion. Thanks for any wisdom and guidance. Jimmie

Dec. 14, 2012