October 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANN] Sparta v1.1

by Denis Kudriashov

Hi Dale 2016-10-22 1:20 GMT+02:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: > Denis, > > Sierra seems to have some issues. A couple weeks ago one of our users ran > into a problem with Pharo3.0 and Sierra > Pharo works fine. When I first time load Sparta everything works well. I am not saw any problem. But it crashed when MozServices are starting second time where dll call is failed (last log entry)

Oct. 21, 2016

Re: [Pharo-dev] [ANN] Sparta v1.1

by Dale Henrichs

Denis, Sierra seems to have some issues. A couple weeks ago one of our users ran into a problem with Pharo3.0 and Sierra --- Esteban jumped on that pretty quickly, but then we discovered some additional issues with GemStone and Sierra -- in our case it was a known bug in Sierra and we are waiting for a fix --- the upshot is that GemStone does not properly run on Sierra until that particular bug is fixed or we release a new version of GemStone with patches ... Upshot is that Sierra is apparently not quite ready for prime time ... Dale On 10/21/2016 03:44 PM, Denis Kudriashov wrote: > > 2016-10-19 18:06 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com > <mailto:alex.syrel@gmail.com>>: > > > It can be bootstrapped with the following script: > > Metacello new > baseline: 'Sparta'; > repository: 'github://syrel/sparta:v1.1/src'; > load: #file:core > > Strange crash detected. > I just execute twice this script and pharo crashed. I use Mac sierra. > And here is top of crash.dmp: > C stack backtrace & registers: > eax 0x0f986260 ebx 0x00000000 ecx 0x00000000 edx 0x00000000 > edi 0x103bfc4e esi 0x103bfc4e ebp 0xbff58bf8 esp 0xbff58bd0 > eip 0x103bfcd4 > 0 libMoz2D.dylib 0x103bfcd4 > _ZN22nsComponentManagerImpl4InitEv + 148 > 1 Pharo 0x00067b16 reportStackState + 166 > Smalltalk stack dump: > 0xbff69b60 I MozServices class>primStartServices 0xca6c830: a(n) > MozServices class > 0xbff69b80 I MozServices class>start 0xca6c830: a(n) MozServices class

Oct. 21, 2016

Re: [Pharo-dev] [ANN] Sparta v1.1

by Denis Kudriashov

2016-10-19 18:06 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > > It can be bootstrapped with the following script: > > Metacello new > baseline: 'Sparta'; > repository: 'github://syrel/sparta:v1.1/src'; > load: #file:core > > Strange crash detected. I just execute twice this script and pharo crashed. I use Mac sierra. And here is top of crash.dmp: C stack backtrace & registers: eax 0x0f986260 ebx 0x00000000 ecx 0x00000000 edx 0x00000000 edi 0x103bfc4e esi 0x103bfc4e ebp 0xbff58bf8 esp 0xbff58bd0 eip 0x103bfcd4 0 libMoz2D.dylib 0x103bfcd4 _ZN22nsComponentManagerImpl4InitEv + 148 1 Pharo 0x00067b16 reportStackState + 166 Smalltalk stack dump: 0xbff69b60 I MozServices class>primStartServices 0xca6c830: a(n) MozServices class 0xbff69b80 I MozServices class>start 0xca6c830: a(n) MozServices class

Oct. 21, 2016

Re: [Pharo-dev] [ANN] Sparta v1.1

by Dale Henrichs

On 10/21/2016 07:30 AM, Norbert Hartl wrote: > Dale, > >> Am 21.10.2016 um 16:12 schrieb Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com >> <mailto:dale.henrichs@gemtalksystems.com>>: >> >> Norbert, >> >> I didn't realize that you were claiming that the new text model for >> Sparta was (potentially) inferior. >> >> The other day you were expressing sadness about having to use the >> newer version of Metacello (which is *only* 3 years old), so I >> assumed that you were just being generally cranky about change:). >> > it might be true it is a current topic for me. In my struggle to > establish a solid devlopment process I have sometimes the feeling it > is impossible. Especially when the new metacello thingie improves > something I don't know but at the same time I loose Versionner and the > commandline handlers which I know :) > The current (!) complaint is rather based on the fact that everything > regarding the graphics backend, widget and tools appears sometimes as > an indefinite loop of reinventing stuff and improving and never get > the job done. Did I mention 64bit, UFFI,â¦ I'm glad all these topics > are worked one and I see a bright future if half of them are done. But > then sometimes it looks rather dark and the light at the end of the > tunnel just went off :) > > <dark mode off/> > Okay, so you _are_ being generally cranky:) FWIW, I took great pains to ensure the the old way of using Metacello continued to work the old (buggy) way while introducing the new (non-buggy) way and that you should be happy to only start feeling the pain of this new feature 3 years after it was introduced:) I should also note that I have no plans to remove the old way of doing things, even though I don't recommend that anyone use the old way anymore ... At GemStone we have users running on 20 year old versions of our product, so I have an appreciation for "legacy users." If you are using filetree based projects then the only way to access them is the new way... Regarding the "command-line", did you know that once you've loaded a project using the new way, that you can re-load a project using the following shorter smalltalk script: Metacello image baseline: 'AAA'; load I made a sweep through the docs a couple of years ago, but since no one seemed to be interested in using the new API I found other things to do ... and now that there's more interest in the "new way" I simply don't have the time (right now) to make another pass through the docs ... so you can be cranky about that too :) Dale

Oct. 21, 2016

Re: [Pharo-dev] [ANN] Sparta v1.1

by Dimitris Chloupis

Actually you are wrong, its not hard to use C libraries from Pharo. UFFI is not a restart, its a continuation of Nativeboost , they are very similar. Pharo FFI, whether its the old FFI, Alien, Nativeboost or UFFI, is more or less the same. In the end an FFI is defined by C syntax , Pharo UFFI borrows the easy of use of Nativeboost that allows you to take c functions definition and use them as they are with a simple copy paste. Pharo is also is based on very good integration with C , like Squeak can output its code as C code via the Slang interface though it comes with some limitations. The availability of C libraries to Pharo is a reflection of the community size. Comparing with Ruby is very unfair , as Ruby is vastly more popular (think in thousand times) , hence why you see so many C libraries wrapped for Ruby. Of course python kicks Ruby ass kung fu style with its vastly superior array of C wrapped libraries. The moment you decide to use an unpopular language as Pharo then if you are not prepared to get your hands dirty and you expect things on your plate like Ruby or Python , then its time to go back to Ruby or Python. Pharo is not in flux , its evolving, every new tool or library you see is an evolution of something else. We dont need Gems for Pharo, Dale has done a great job with Metacello, its easy to make a pharo project in git/github and have it install all pharo code and built C libraries wrapped for Pharo. Just because people are not in the habit of doing this does not mean its not super easy to be done. For example AFAIK my project ChronosManager was one of the first project to install from Catalog Browser not only its Pharo code but also , pngs and audio files. I made even an autoupdate feature that pings my github repo to see if there are any new commits and then if so it alerts the user and give him the ability to download the update with a single click. All that is metacello. Metacello is probably one of the best if not the best package distribution systems out there. Definetly vastly better than Python's PyPi and Node'js NPM . I cannot praise it enough and I have no problem criticising Pharo when I must. Dale has done an amazing job, period. On the GUI front on the other hand, its messy, no doubt about it. Morphic is huge, ugly and almost not maintained. Bloc is probably going to be the next step. I think the issue here is that we dont have Arduino or Raspberry Pi guys. Same story for my field, 3d graphics. There is a OpenGL wrapper and the Wodden graphics engine and nothing else. I and the author of Woden are the only people here interested into 3d graphics, he makes Woden, I have made a bridge with Blender Python , for using Pharo to make Blender addons and I am now in the process of making a bridge with Unreal Engine. I dont see why you would have an issue using Pharo from Raspberry Pi, we already support SDL and you can even run Pharo with no GUI from the terminal and export any Pharo method as a command line argument. My Python socket bridge also showed me that is dead easy to connect Pharo with other programming languages, in my case python , with just a few hundred lines of code. Typical IPC. So there are no excuses for not using Pharo, from there on, it depends on your specific needs and wants and taste. On Fri, Oct 21, 2016 at 7:05 PM Todd Blanchard <tblanchard(a)mac.com> wrote: > > On Oct 21, 2016, at 07:30, Norbert Hartl <norbert(a)hartl.name> wrote: > > The current (!) complaint is rather based on the fact that everything > regarding the graphics backend, widget and tools appears sometimes as an > indefinite loop of reinventing stuff and improving and never get the job > done. Did I mention 64bit, UFFI,â¦ I'm glad all these topics are worked one > and I see a bright future if half of them are done. But then sometimes it > looks rather dark and the light at the end of the tunnel just went off :) > > > I feel you. > > I very much want to use Pharo to build devices from things like Raspberry > Pi's, iPhones, and Androids. I need access to native libraries. You can't > rewrite everything ever in Smalltalk and I don't really see a good reason > to. > > I've taken about ten years off from doing Smalltalk and I'm trying to get > back into it. My interest is piqued because I want to build nice custom > systems using the nifty new cheap goodies like Arduinos and RPis and it > seems tossing together a full screen Pharo image would be a great way to > build these appliances. In that time the story for how to call out to > native code has changed...twice. Everything is broken or in flux again. > > To me, it doesn't feel like there's any more platform to build apps on > than there was ten years ago and everything is still "just around the > corner". Pharo seem to be an experiment in building next generation > programming tools using deprecated last generation programming tools. I > don't see a lot of useful programs being built atop it - largely because > the base is constantly shifting about. > > It is disheartening that the Ruby guys can crank out gems with native > libraries that compile and work on every platform and pharo is still > constantly half broken with loadable native code "doable" but only with > great effort. > > I looked and Moz2D doesn't seem to have a light weight build for Raspberry > Pi. Is hitching Pharo to a heavy weight graphics library as a core > requirement a good idea? > > I'm starting to think maybe we need something like Gems for Pharo - > dynamically loadable libraries and resources - compiled at install if > necessary. >

Oct. 21, 2016

Re: [Pharo-dev] Git versions on CI slaves

by Mark Bestley

On 21/10/2016 15:04, Damien Pollet wrote: > On 21 October 2016 at 15:47, Pavel Krivanek > <pavel.krivanek(a)gmail.com > <mailto:pavel.krivanek@gmail.com>> wrote: > > The main problem are the long-term supported Linux distributions > like Debian or CentOS. > > > Even Debian stable has git 2.1 so I'd say it's a non-problem. > > See git's release dates (albeit via wikipedia) https://en.wikipedia.org/wiki/Git Both 1.7 and 1.8 are unsupported as is 2.1 Current version is 2.10 -- Mark

Oct. 21, 2016

Re: [Pharo-dev] [ANN] Sparta v1.1

by Todd Blanchard

> On Oct 21, 2016, at 07:30, Norbert Hartl <norbert(a)hartl.name> wrote: > > The current (!) complaint is rather based on the fact that everything regarding the graphics backend, widget and tools appears sometimes as an indefinite loop of reinventing stuff and improving and never get the job done. Did I mention 64bit, UFFI,â¦ I'm glad all these topics are worked one and I see a bright future if half of them are done. But then sometimes it looks rather dark and the light at the end of the tunnel just went off :) I feel you. I very much want to use Pharo to build devices from things like Raspberry Pi's, iPhones, and Androids. I need access to native libraries. You can't rewrite everything ever in Smalltalk and I don't really see a good reason to. I've taken about ten years off from doing Smalltalk and I'm trying to get back into it. My interest is piqued because I want to build nice custom systems using the nifty new cheap goodies like Arduinos and RPis and it seems tossing together a full screen Pharo image would be a great way to build these appliances. In that time the story for how to call out to native code has changed...twice. Everything is broken or in flux again. To me, it doesn't feel like there's any more platform to build apps on than there was ten years ago and everything is still "just around the corner". Pharo seem to be an experiment in building next generation programming tools using deprecated last generation programming tools. I don't see a lot of useful programs being built atop it - largely because the base is constantly shifting about. It is disheartening that the Ruby guys can crank out gems with native libraries that compile and work on every platform and pharo is still constantly half broken with loadable native code "doable" but only with great effort. I looked and Moz2D doesn't seem to have a light weight build for Raspberry Pi. Is hitching Pharo to a heavy weight graphics library as a core requirement a good idea? I'm starting to think maybe we need something like Gems for Pharo - dynamically loadable libraries and resources - compiled at install if necessary.

Oct. 21, 2016

Re: [Pharo-dev] [ANN] Sparta v1.1

by Sven Van Caekenberghe

> On 21 Oct 2016, at 17:19, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> >> On 21 Oct 2016, at 16:43, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Tudor Girba-2 wrote >>> I would kindly ask for patience. What is perhaps less clear is that this >>> editor is in the critical path of the GT project and we are committed to >>> deliver an editor that actually works. We are still investigating >>> different paths, both on the low level (like with Rope) and at the higher >>> level (like how to organize the layout). >> >> I really appreciate your long-term vision. My point/concern is that IMHO the >> most important thing is to "rachet up" - to alternate frequently between: >> a) releasing working versions of current best ideas (the many benefits of >> which include locking in progress, getting feedback from a wide audience, >> and getting buy-in/allowing users to adapt), and >> b) using that as a launching point for new experiments >> >> We are still using the same original awful text model that has stymied so >> many users/projects! Let's focus on and release something useable - anything >> - to take the pressure off while we invent the future. >> >> To illustrate the general principal, think about all the pain we have >> experienced because the last (promised) crucial step of cleaning and >> refactoring Squeak was not accomplished before beginning the next >> experiment! My question is: where is the sweet spot between the zero vision >> (but universal accessibility for actual work) of Java/C++, and infinite >> vision (at the extreme cost of immediately-usable artifacts) of >> Squeak/VPRI[1]? > > amen. > > think is: is like the third time we start once again to build the next huge steps. > and frankly, while waiting for that we have a text model that sucks and a cool text model unfinished and usable and a text editor that cannot handle complicated stuff because it is not ready, etc. etc. > it feels bad. it tastes bad. and is not good at all. Yes, that does not feel good. But the fact that something is not completely finished is in the first place the responsibility of who started it in the first place - they did not drive there work all the way through (including integration, documentation, actively supporting it for a couple of years). > Esteban > >> >> 1. This is not a criticism; they are just in a different business (cathedral >> building) >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/ANN-Sparta-v1-1-tp4919394p4919647.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 21, 2016

Re: [Pharo-dev] [ANN] Sparta v1.1

by Esteban Lorenzano

> On 21 Oct 2016, at 16:43, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Tudor Girba-2 wrote >> I would kindly ask for patience. What is perhaps less clear is that this >> editor is in the critical path of the GT project and we are committed to >> deliver an editor that actually works. We are still investigating >> different paths, both on the low level (like with Rope) and at the higher >> level (like how to organize the layout). > > I really appreciate your long-term vision. My point/concern is that IMHO the > most important thing is to "rachet up" - to alternate frequently between: > a) releasing working versions of current best ideas (the many benefits of > which include locking in progress, getting feedback from a wide audience, > and getting buy-in/allowing users to adapt), and > b) using that as a launching point for new experiments > > We are still using the same original awful text model that has stymied so > many users/projects! Let's focus on and release something useable - anything > - to take the pressure off while we invent the future. > > To illustrate the general principal, think about all the pain we have > experienced because the last (promised) crucial step of cleaning and > refactoring Squeak was not accomplished before beginning the next > experiment! My question is: where is the sweet spot between the zero vision > (but universal accessibility for actual work) of Java/C++, and infinite > vision (at the extreme cost of immediately-usable artifacts) of > Squeak/VPRI[1]? amen. think is: is like the third time we start once again to build the next huge steps. and frankly, while waiting for that we have a text model that sucks and a cool text model unfinished and usable and a text editor that cannot handle complicated stuff because it is not ready, etc. etc. it feels bad. it tastes bad. and is not good at all. Esteban > > 1. This is not a criticism; they are just in a different business (cathedral > building) > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/ANN-Sparta-v1-1-tp4919394p4919647.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Oct. 21, 2016

Re: [Pharo-dev] Again about scrolling with a trackpad

by Denis Kudriashov

2016-10-21 16:44 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > If I remember correctly on side scrolling the vm generates "ctrl + â" and > "ctrl + â" keystroke events. Then some morph listens to them and switches > focus. > I hope with SDL it will be normal events

Oct. 21, 2016