September 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

by Martin McClure

On 09/15/2014 11:54 AM, Eliot Miranda wrote: > Agreed. But one real problem with the Squeak/Pharo UI is the lack of > native windows. There is an old project Graphics-External-Ffenestri but > AFAICT it isn't being used. But there /is/ a really good prototype of a > native window system above Squeak done by Vassili Bykov in Newspeak. > The native windows contain morphs, but anything, including MVC, can be > present. This provides native Win32 Windows (doing other platforms is > merely work) /and/ the ability to snapshot and bring back up windows on > a different platform (e.g. open in win32, snapshot and bring up in > Squeak/Pharo Morphic windows, or vice verse), and the ability to do this > dynamically. Is anyone motivated to port the Newspeak code back to > Squeak/Pharo? > > > If you're interested, contact me, or Vassili, or Bob Westergaard and ask > about Brazil (think plumbing). > By coincidence, this week I dusted off my project (shelved about a year and a half ago) to port Brazil and Hopscotch to Smalltalk. And have made some progress, though it's still very early stages. If anyone else is interested in helping move this forward more quickly, let me know... Regards, -Martin

Sept. 19, 2014

Re: [Pharo-dev] How production ready is Pharo on SQLServer?

by Sebastian Sastre

For the record, adding some offlist info Iâve got: Here at the bottom there are binaries: http://www.linuxnetworks.de/doc/index.php/OpenDBX/Download#Windows_DLLs And Iâm attaching this screenshot of the problem I saw in a fresh Pharo 3, following the instructions found here: http://dbxtalk.smallworks.com.ar/DBXTalkDrivers/ No stable version for Pharo 3.0, I had the impression that there where people using it in Pharo 3, isnât it? or maybe thatâs an unmaintained repo? trying a dirty hack which tries to load the same of a 2.0 for a 3.0, continues some and then shows this problem: And after trying to remove that startUp line to see how far it can go without that, I found this: And Iâm stuck is that the right repo? suggestions? what should I do? thanks! sebastian o/ blog: http://sebastianconcept.com LinkedIn: http://www.linkedin.com/in/sebastiansastre github: https://github.com/sebastianconcept On Sep 16, 2014, at 11:49 PM, Sebastian Sastre <SEBASTIAN(a)FLOWINGCONCEPT.COM> wrote: > I'm trying to follow instructions from here: > http://dbxtalk.smallworks.eu/DBXTalkDrivers/compiling-and-installing-opendb… > > but the link about the binaries for Windows is broken > > suggestions? > > from iPad > > On 12/09/2014, at 17:21, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >> ok, I'll try dbx and think of odbc as plan b >> >> from iPad >> >> On 12/09/2014, at 17:14, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: >> >>> DBXTalk is probably right. If it doesn't work, the old ODBC package will work - I have tried that later one (not against SQLServer, but it's just ODBC, so will work). >>> >>> -cbc >>> >>> On Fri, Sep 12, 2014 at 12:37 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>> 2014-09-11 17:48 GMT-03:00 Sebastian Sastre <sebastian(a)flowingconcept.com>: >>> > Hi guys, >>> > >>> > there is a project that needs to connect and extend a system using SQLServer >>> > and Pharo is being considered for the backend. >>> > >>> > Just checking, how ready are we for a production-ready backend using Pharo >>> > on SQLServer? >>> >>> (absent) >>> >>> > and how do we connect to it? >>> >>> DBXTalk, probably, but really can't tell. >>> >>> Database connectivity, other than PostgreSQL seems to be rather >>> infrequent, if used at all. >>> >>> >>> Esteban A. Maringolo >>> >>>

Sept. 19, 2014

Re: [Pharo-dev] Parsing Pharo syntax to C/C++

by Andres Valloud

Side comments... Some code just has to be written in C, otherwise you cannot rely on the behavior being correct and ultimately that's a major show stopper for anything you might want to call "production" code. Anything having to do with calling operating system libraries is a typical example of this phenomenon. So, in those cases, translating Smalltalk to C (or interfacing to OS libraries with FFI interfaces) only gives you huge maintenance headaches in the long run. The resulting distractions due to bug reports will obliterate any engineering team's performance, and it's a race that cannot be won as framed. POSIX is there for a reason, let the C compiler do the job it's been doing for 40+ years. But suppose one wants to write C code with Smalltalk syntax anyway. Nevertheless, C99 and newer still apply and one must be aware of the subject matter. The danger is that Smalltalk is so much more user friendly than C, that once one starts writing C in Smalltalk one will never look at the automatically generated C. But is the mechanically generated C code valid? Because if not, then compiling such source code can be no better than "garbage in, garbage out", and then you cannot have production quality. Similar arguments apply to FFI interfaces. Please excuse my ignorance, but I'd like to assume someone's looking into this? What seems to follow is that the architecture of the system should try to minimize the dependencies on external libraries, precisely because the dependencies cause exposure to foreign rules and regulations that slow one down. Creating dependencies in a reasonable manner should be straightforward _for system users_, though. Letting externals create reliable dependencies on one's system should also be facilitated to promote healthy modes of interaction with the community at large. I feel one of our current challenges is to wholeheartedly admit there is no royal road to inventing our future, then act accordingly. Andres.

Sept. 19, 2014

Re: [Pharo-dev] [Vm-dev] re: Parsing Pharo syntax to C/C++

by kilon alios

"Nope. As a C/C++ advocate you are in denial about how unproductive your tools are and about the fact that it takes industrial scale organization to achieve even the most trivial of achievements." C/C++ , I don't code in those languages. Currently I use pharo, before that I was coding in python and still do, before that I was a Delphi developer. I hate C++ with a vengeance.I am now learning C for my first time. I dont see the industry having any problem achieving what it wants with C/C++ because if it did then the software industry would be overrun by smalltalk , which we all know how superior better it is . Actually you will be lucky if a coder was even aware what smalltalk is. I did not know what smalltalk is like a few years ago. I never even saw it mentioned in coding forums or in chat channels until one day someone mentioned squeak to me in #emacs. "By recently I mean within the last 10 years or so. The HotSpot Smalltalk VM is already 19 years old, and Self 3 over 20. PS, the first truly fast VM for a dynamic object oriented language is 32 years old. Python could have started an implementation effort at a faster VM much sooner and it would have shaped Python, IMO positively. There are reasons Java has been much more popular until recently, performance being a very important one. (There's reasons it's no longer popular, IMO the most important being it being statically typed). Further if you read what the Dropbox guys (and many others) are saying about Pyston vs PyPy is that tracing JITs fail to deliver good performance except in synthetic benchmarks where they shine, and hence Pyston is a method-at-a-time JIT. So PyPy is a so-so VM, hardly in the same league as HotSpot or V8 (and Pyston will have a ways to go before i can compete on that level), just as Cog is a so-so VM and needs Sista to reach or exceed static language performance for non-symbolic codes. And the lack of good support for C/C++ in PyPy is not a technical limitation. It is an organizational one. There's nothing intrinsic in a fast VM that makes it more difficult to interface to C. An execution engine is an execution engine, and it is the object representation that determines how easy it is to interface to other languages." Bottom line is clear, do optimised VMs are likely to really interest people, from the looks of it does not seem so. I don't care whether PyPy has technical limitations what matters is that I cannot use my favorite cpython libraries with it. " And that pure python libraries are a rarity is of course a result of the fact that Python has run to C whenever it needed performance. Hence when one comes to measure the speedup of a fast python against cpython it is difficult to see speedups because lots of benchmarks (e.g. many of the computer language shootout benchmarks) are spending much of their time running C code. Hint, if an app spends 50% of its time in C then it can never be more than twice as fast on a faster execution engine." no python needs to run C libraries because it wants to run C libraries , because they are so many out there and many of them are so damn good at what they are doing. Actually nowadays it becomes increasingly difficult not to find python wrappers for a C/C++ library. It comes down to C/C++ coders needing a simpler language that can easily port their code a lot more than a python coder would need C for speed. "You contradicted yourself in claiming that Pythoners dont yse faster VMs. Java has good C integration and provides much better performance than PyPy so if you were correct Pythoners would be using Jython + C but you claim they're not. (Personally I'm dubious about blanket claims about what people do and don't do; my experience since I've been involved with commercial Smalltalk deployment is that the world is incredibly varied and different people with different requirements do different things, often for good reason)." First of all Java has had crappy C integration like for ages , people were complaining about it for a long long time. Second I dont see how I contradict myself , I claimed that python people don't care so much about how fast a VM is when they can fall back to C and you bring up Java speed. What am I missing her ? Why not use Jython ? simple same reason why people dont use PyPy lack of support for cpython libraries, which by the way are based partly if not largely in C and if Java had so cool support of C then jython would have supported cpython libraries out of the box , which it does not. We can run this in circles but in the end I find it highly suspicious how some smalltalkers find smalltalk so awesome in every level yet they fail to justify why its so unpopular. And just for the record , so people dont think I talk out of random, this is Guido , the creator of python , says about PyPy and why is not integrated to cpython and the main goal of cpython --> http://youtu.be/EBRMq2Ioxsc?t=12m29s And yes python does not care about innovation at all, and this is one of the reason of its immense success as a language. Actually if you take into consideration that python is not tied to platform like javascript , or is not backed up by a huge company like C++ , Java , C# I dont think its an exaggeration at all that to say that it has been by far the most successful language at least in terms of people actually using it. Personally I find python as well completely unoriginal , not that well implemented, very slow and unimaginative. Still its the language, my number one choice, I would recommend to any one in terms of practicality alone. I don't want to debate this to death, I stated my opinion and the my view on things, you can call me advocate , fanboy or plain blind. Thats your right. I think however its good to hear the other side of story , the other opinion to make the discussion a bit more spherical. Saying that I love smalltalk and especially pharo and I hope it keeps being practical enough for me to keep using it.

Sept. 18, 2014

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

by Alexandre Bergel

Wellâ¦ Porting Roassal3d to Woden is almost straightforward :-) We can help on this. Effort behind Woden, Roassal, GraphET are not to simply tools. But instead producing an effective solution for a given problem. So, they will always be changing :-) Cheers, Alexandre On Sep 14, 2014, at 7:28 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > Sometimes it is a bit dangerous to trust on "bleeding edge" pharo frameworks. > I did some work based on Roassal3D just to found out there won't be any further development. > The same happens with Roassal and GraphET. > The same can happen with Woden too :) -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 18, 2014

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

by Alexandre Bergel

Hi Kilon, Not sure what you are trying to do. Try this: -=-=-=-=-=-=-=-=-=-=-=-= forms := Form allInstances. v := RTView new. t := 1. e := (RTBitmap new form: [ :index | forms at: index ]) elementOn: t. v add: e. v open. [ 50 timesRepeat: [ t := t + 1. e model: t. e updateShape. (Delay forMilliseconds: 500) wait. v signalUpdate ] ] fork. -=-=-=-=-=-=-=-=-=-=-=-= Cheers, Alexandre On Sep 14, 2014, at 1:22 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > so I tried to animate in Roassal having two different images display with a delay for few millisecond but it only displays the second image with this code > > form1 :=Form fromFileNamed:'/Users/kilon/Pictures/pharo.png'. > form2 :=Form fromFileNamed:'/Users/kilon/Pictures/box.png'. > v := RTView new. > c := v canvas. > s := TRBitmapShape new. > s form: form1. > c addShape: s. > v open. > > (1 to: 100) do: [ :index| > s form: form1. > s signalUpdate . > "(Delay forMilliseconds: 1000 ) wait." > s form: form2. > s signalUpdate . > (Delay forMilliseconds: 1000) wait.]. > > I looked into RTAnimation but dont know how to use it for this example. Any help ? Does Roassal 2 support such animations ? > > if I do s form: and then s signalUpdate for each form separately it works fine but inside the loops does not seem to work , I tried bigger delays with no effect. > > On Sun, Sep 14, 2014 at 10:57 AM, stepharo <stepharo(a)free.fr> wrote: > Ronie when you ready I can help writting a chapter for the nex book. > > Stef > > > On 13/9/14 21:42, Ronie Salgado wrote: >> Hello, >> >> On 13/9/14 20:11, Enrico Schwass wrote: >>> Hi >>> >>> another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work. >> >> There is Wig like wrapper for Pharo done by ronie salgado. >> >> I have an adapted version of Swig for Pharo NativeBoost here: https://github.com/ronsaldo/swig >> >> Currently I am using it to generate my Bullet bindings (available here: https://github.com/ronsaldo/bullet-pharo) that can be used as an example of using Swig. >> I still have to improve more my Swig generator, by writing documentation and fixing some bugs. >> >> Greetings, >> Ronie >> >> 2014-09-13 16:11 GMT-03:00 stepharo <stepharo(a)free.fr>: >> >> On 13/9/14 20:11, Enrico Schwass wrote: >>> Hi >>> >>> another option could be the verse protocol. There was a plugin for Maya and Blender to do realtime rendering. Dont know if there is some automatic Swig-like wrapper for smalltalk but FFI might work. >> >> There is Wig like wrapper for Pharo done by ronie salgado. >> >> Stef >> >> >>> >>> http://youtu.be/c_D2YJSNj8I >>> >>> Almost a decade ago I did some ruby bindings by hand. It was working out of the box >>> >>> Bye >>> Enno >>> >>> Am 13.09.2014 um 16:11 schrieb kilon alios <kilon.alios(a)gmail.com>: >>> >>>> >>>> " I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? " >>>> >>>> yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file. >>>> >>>> So basically its a lot like the average games out there. >>>> >>>> "I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing." >>>> >>>> ok >>>> >>>> "For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result." >>>> >>>> I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things. >>>> >>>> "Sure. The downpoint, you will depend on one additional layer." >>>> >>>> dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large. >>>> >>>> "Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious." >>>> >>>> Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically. >>>> >>>> So basically you will be using Blender as a GUI designer. >>>> >>>> "Use fuel to store the state of your application objects." >>>> >>>> ah nice so fuel is a good candidate. >>>> >>>> I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) . >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 18, 2014

Re: [Pharo-dev] [Vm-dev] re: Parsing Pharo syntax to C/C++

by Eliot Miranda

On Thu, Sep 18, 2014 at 2:25 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > " and that's precisely what we want to avoid. IMO that;s one reason why > the Python (and e.g. PHP) community has been so slow to implement good VMs. > It has deferred to C code for performance-critical code _where it could_ > (e.g. regular expressions) at the expense of rigid dependence on that > external library. Now that companies such as Dropbox and Facebook are > needing Python and PHP to exhibit good performance they are finally > implementing faster VMs long after other languages. " > > nope , you are close but you got it the other way around. As a smalltalker > you see it from purist way of view. For you Python is that language that > got caught up on too reliance on C/C++ libraries. > Nope. As a C/C++ advocate you are in denial about how unproductive your tools are and about the fact that it takes industrial scale organization to achieve even the most trivial of achievements. > What you see as side effect is actually the central goal of python. The > central goal of python was and still is to a great extend today to serve as > scripting language for C and C++ code. This what made python so successful > that a C/C++ coder could use on top of its app embedded inside its app. > This why so many people use it even today. > Nope. What you claim as a central goal of Python is merely a supine acceptance of massive failure to innovate. Bourne shell has been doing this for years and years. It's not a new thing. And GVR seems to have conceived it as a better shell. Well, that's not innovative; useful, yes, innovative no. But seriously, look at something innovative written in Python such as BitTorrent et al. How much of that is system calls, C or Python? t is basically Python an socket calls. C doesn't play a significant part in the architecture. The important thing is a dynamic OOPL being able to express a novel architecture. I'd wager that torrent clients are amongst the most popular Python apps. You also again wrong to assume that its a late thing that new VMs are > developed for Python , PyPy which is very well known inside the python > community has been around more than 12 years. Its a very performant JIT VM > 2-10 faster than cpython. Why cpython has not ported to it ? because of not > so good support for C/C++ , zero support for cpython libraries and of > course because as they say it would complicate the development of cpython > quite a lot . Its that situation that only a couple of people can decypher > the magic of the VM and the rest of developer only hope for the best. > By recently I mean within the last 10 years or so. The HotSpot Smalltalk VM is already 19 years old, and Self 3 over 20. PS, the first truly fast VM for a dynamic object oriented language is 32 years old. Python could have started an implementation effort at a faster VM much sooner and it would have shaped Python, IMO positively. There are reasons Java has been much more popular until recently, performance being a very important one. (There's reasons it's no longer popular, IMO the most important being it being statically typed). Further if you read what the Dropbox guys (and many others) are saying about Pyston vs PyPy is that tracing JITs fail to deliver good performance except in synthetic benchmarks where they shine, and hence Pyston is a method-at-a-time JIT. So PyPy is a so-so VM, hardly in the same league as HotSpot or V8 (and Pyston will have a ways to go before i can compete on that level), just as Cog is a so-so VM and needs Sista to reach or exceed static language performance for non-symbolic codes. And the lack of good support for C/C++ in PyPy is not a technical limitation. It is an organizational one. There's nothing intrinsic in a fast VM that makes it more difficult to interface to C. An execution engine is an execution engine, and it is the object representation that determines how easy it is to interface to other languages. And PyPy is not the only JIT VM for python , there is also Jython that runs > of JVM and ironpython that runs on .NET and Mono. What those 3 have in > common ?that are used by a tiny crowd compared to people using cpython. > That could be because foreign VMs don't provide the support that users of a VM designed for a language expect, could it not? IMO this is a really important issue, especially for Smalltalk where we expect instance migration, contexts, etc, all of which one has to say goodbye to when hosted on a foreign VM. And this is a major reason for putting effort into one's own infrastructure. The truth is pure python libraries are a rarity . Why you think the most > popular , by far, implementation of python is called cpython ? I will give > you a hint, 50% of its source code is written in C. No thats not just the > VM its libraries and cpython comes with a lot of libraries included. > And that pure python libraries are a rarity is of course a result of the fact that Python has run to C whenever it needed performance. Hence when one comes to measure the speedup of a fast python against cpython it is difficult to see speedups because lots of benchmarks (e.g. many of the computer language shootout benchmarks) are spending much of their time running C code. Hint, if an app spends 50% of its time in C then it can never be more than twice as fast on a faster execution engine. Frankly I dont believe that any VM ever however fast will ever beat smooth > integration of C/C++ code unless you have a huge company to back you up > with an insane amount of libraries. Java had Sun , .NET has still > Microsoft. > Seriously, what do you mean "beat"? The world is infinitely varied. COBOL is still important and yet you seem to portray the entire programming field as reducing to some kind of horse race. What's the content here? Also what's the intent behind pissing contests? Seems rather teenage. Whereas being positive, doing good engineering and innovating can invent the future. Seem much more fun than doling out endless negativity. > For people that speed is a serious matter even if a VM is a mere 30% > slower than optimised C code, they will take the C code any day. > You contradicted yourself in claiming that Pythoners dont yse faster VMs. Java has good C integration and provides much better performance than PyPy so if you were correct Pythoners would be using Jython + C but you claim they're not. (Personally I'm dubious about blanket claims about what people do and don't do; my experience since I've been involved with commercial Smalltalk deployment is that the world is incredibly varied and different people with different requirements do different things, often for good reason). Speed is pretty meaningless unless you qualify it. In applications where performance can really matter theres always assembler (e.g. video decoders) or DSPs or... and often optimized C just doesn't hack it. But so what? There is another context where using Scheme to automatically generate Java VMs is critical to performance. And one can cite example after example where high performance does /not/ equal C/C++ plus an insane number of libraries. Computing is a broad church. There are plenty of contexts where time to market is the dominant factor and that can force one to reject performant and difficult to configure solutions (such as Jython, or Smalltalk + C), but equally there are contexts where time to market is the dominant factor and that can "force" one to use pure dynamic OOPLs because the world changes too fast to do anything else (e.g. finance). Anyway, keep those "nope"s coming. I love them. Time to patent your new way of proving a negative I think. -- best, Eliot

Sept. 18, 2014

Re: [Pharo-dev] [Vm-dev] re: Parsing Pharo syntax to C/C++

by kilon alios

" and that's precisely what we want to avoid. IMO that;s one reason why the Python (and e.g. PHP) community has been so slow to implement good VMs. It has deferred to C code for performance-critical code _where it could_ (e.g. regular expressions) at the expense of rigid dependence on that external library. Now that companies such as Dropbox and Facebook are needing Python and PHP to exhibit good performance they are finally implementing faster VMs long after other languages. " nope , you are close but you got it the other way around. As a smalltalker you see it from purist way of view. For you Python is that language that got caught up on too reliance on C/C++ libraries. What you see as side effect is actually the central goal of python. The central goal of python was and still is to a great extend today to serve as scripting language for C and C++ code. This what made python so successful that a C/C++ coder could use on top of its app embedded inside its app. This why so many people use it even today. You also again wrong to assume that its a late thing that new VMs are developed for Python , PyPy which is very well known inside the python community has been around more than 12 years. Its a very performant JIT VM 2-10 faster than cpython. Why cpython has not ported to it ? because of not so good support for C/C++ , zero support for cpython libraries and of course because as they say it would complicate the development of cpython quite a lot . Its that situation that only a couple of people can decypher the magic of the VM and the rest of developer only hope for the best. And PyPy is not the only JIT VM for python , there is also Jython that runs of JVM and ironpython that runs on .NET and Mono. What those 3 have in common ?that are used by a tiny crowd compared to people using cpython. The truth is pure python libraries are a rarity . Why you think the most popular , by far, implementation of python is called cpython ? I will give you a hint, 50% of its source code is written in C. No thats not just the VM its libraries and cpython comes with a lot of libraries included. Frankly I dont believe that any VM ever however fast will ever beat smooth integration of C/C++ code unless you have a huge company to back you up with an insane amount of libraries. Java had Sun , .NET has still Microsoft. For people that speed is a serious matter even if a VM is a mere 30% slower than optimised C code, they will take the C code any day.

Sept. 18, 2014

Re: [Pharo-dev] I'm confused about Process>>isTerminated

by Bob Westergaard

Why not use #waitTimeoutMsecs:? Something like: greenLight := Semaphore new. process := [started := true. [Semaphore new wait] ensure: [terminator := Processor activeProcess. unwound := true]. greenLight signal] forkAt: Processor activeProcess priority -1. expired := greenLight waitTimeoutMSecs: 1000. "or whatever suits you" deny: expired. assert: process isTerminated. " and so on" -- Bob

Sept. 18, 2014

Re: [Pharo-dev] [squeak-dev] Re: The Dilemma: Building a Futuristic GUI for Ephestos

by Eliot Miranda

Hi Torsten, wow, what a great summary. Thanks. See below. On Wed, Sep 17, 2014 at 12:09 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Eliot wrote: > >We're getting there with fast. Tiny needs more definition, but the core > Cog/Spur VM on Mac minus plugins and GUI >code is 568k, 506k code, 63k > data; the newspeak VM which has fewer primitives but support for two > bytecode sets is >453k, 386k code, 68k data. That includes the > interpreter, JIT, core primitives and memory manager/GC. Add on >several k > for the FFI, C library et al and a VM in a megabyte is realistic. Is that > in the right ball park? > > Yes, wet's my appetite :) > > Tiny means easy to download and use for scripting, no other dependencies > for the out of the box REPL experience. But still powerfull to built one > on another > and scale up to large programs. > > Initially you provide just a simple VM executable for a "tiny smalltalk" > (ts), for simple > things like: > > c:\myscripts\ts.exe -e 3+4 > 7 > > where ts.exe is the VM in a few kB including a small initial kernel image > (as part of > the PE DATA section). It should be able to run scripts: > > c:\myscripst\ts.exe automate.st > > It should be possible to easily build components (either with or without > the sources): > > ts.exe sunit.st -o sunit.sll > ts.exe sunit.st -noSource -o sunit.sll > > So you can either include other scripts > > ts.exe -i sunit.st mytests.st > > or link the previously built binary components to form something new. > > ts.exe -l junit.sll mytests.st > > But it should be possible to build another vm+image easily: > > ts.exe -i mykillerapp.st -o killerapp.exe > or ts.exe -l mykillerapp.sll -o killerapp.exe > > by writing a new PE file for Windows either including a new kernel image > or a combined > one based on the already built-in initial kernel of the previous one. > So I can deploy a killerapp or reassemble it to form the next language > version. > > SmallScript was very close to that and it was a nice thing to work with. > Especially since usually Smalltalk usually throws things out at the end - > but > one never builds a house by carving it out of a rock. We need bricks to > assemble. > +1000. With the above scheme you could build components, some of them portable, > others > explicitly non-portable as the code includes native calls. The later have > to > be rebuilt on the other platform - so if you have good design abstractions > you > can implement a UI lib on Windows and one on Mac. > > Some of the components are with the source code packaged in for debugging > (but not changeable), for closed source components you leave it out. > > And still it should support pinnable objects (not moved by GC for > callouts), > sandboxing, Classes with UUIDs to allow for side by side loading/migration > and an extensible meta-scheme as this is where Smalltalk is still the hero > of all > und metaprogramming will be our future. > So so far I have pinning. But I'd love to hear more detail on sandboxing. I'm not sure about UUIDs. What about other mechanisms, namespaces, ClassBoxes? UUID sounds too much like an implementation to me. No one is proposing qualifying class names with UUIDs (Array:c5c09212-0c7d-44f3-81b7-18ae5d7f14d9 new: 5 ????). How about reitierating this more abstractly? Also the VM should be available as a shared component - so it can run > in-process > in other programs like a web browser. Always wished to write: > > <script type="text/tinyscript"> > BrowserLog write: 'HelloWorld'. > </script> > > directly in HTML. > > And this is only the beginning of the wish list... > Please, I'd love to have you write a fuller list. We could add it to the list at Cog Projects <http://www.mirandabanda.org/cogblog/cog-projects/> or add it to a "Directions" page or some such. But capturing these ideas is importasnt. >Yep. But personally I think Fuel is better and just as fast. Certainly > that's the parcels experience. > > - but still with the ability to bootstrap up to a full saveable image > > Yes, Fuel would be an option. At least it would be platform independent. > Not sure > about other options (quick loading by mapping component using memory > mapped files etc.) > Well, mapping finished images a la VW's PermSpace is probably easier. The memory mapping in .Nt is extremely complex. But I get the requirement; ultra-fast start-up of small components. > >This we'll leave to the web framework designers, but it seems eminently > doable no? > > For sure. > > Bye > Torsten > thanks again. And give serious thought to carefully enunciating these requirements/this design sketch? -- best, Eliot

Sept. 18, 2014