Smalltalk › Pharo › Pharo Smalltalk Developers

[ANN] Sparta v1.1

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

104 messages Options

123456

Denis Kudriashov

Re: [ANN] Sparta v1.1

2016-10-19 18:06 GMT+02:00 Aliaksei Syrel <[hidden email]>:

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

Dale Henrichs-3

Re: [ANN] Sparta v1.1

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 <[hidden email]>:
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

Denis Kudriashov

Re: [ANN] Sparta v1.1

Hi Dale

2016-10-22 1:20 GMT+02:00 Dale Henrichs <[hidden email]>:

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)

Denis Kudriashov

Re: [ANN] Sparta v1.1

In reply to this post by Denis Kudriashov

2016-10-21 16:20 GMT+02:00 Denis Kudriashov <[hidden email]>:

2016-10-21 16:15 GMT+02:00 Tudor Girba <[hidden email]>:
> 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 am not against to any new implementation of existing stuff. It is always interesting how things could be done different and especially if it provides better solution.
> But I really fear that new text experiments will dramatically delay releaze of Bloc and Sparta and following migration to new UI. And this is real importance for Pharo future, and not possible moldable editor.
> Text editors are very complex domain. It takes more than year to get working TxText and Twisty. Why not finish Bloc and Sparta with minimal effort on adopting TxText or Twisty to run on them?

I think there is a confusion here. Sparta was just released on all three OSs (a major effort of Alex), Bloc is working and it even has TxText working there on top of Sparta (another major effort of Glenn).

If it is done then no complains from me. It is super cool.

Unfortunately I not found TxText integration in dev Bloc. BlText uses new model.

Dale Henrichs-3

Re: [ANN] Sparta v1.1

In reply to this post by Denis Kudriashov

Right, but since there are known bugs in Sierra perhaps MozServices is hitting one of them.

In our case we hit a bug in poll() which is a bit surprising and apparently the bug is hitting Apple's own curl implementation -- see discussion here[1]...

Dale

[1] https://github.com/curl/curl/issues/1057

On 10/21/2016 04:56 PM, Denis Kudriashov wrote:

Hi Dale

2016-10-22 1:20 GMT+02:00 Dale Henrichs <[hidden email]>:

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)

philippeback

Re: [ANN] Sparta v1.1

In reply to this post by kilon.alios

We need some easy to use gem-style installer on the command line.

Pharo is perfectly usable for any kind of project provided energy is poured in.

Things are in flux, yes, and it is frustrating not to have it all perfect. So what? If we weren't interested in wild things why would we be here after all?

Think long term: 10 years from now, improvements will have been massively compounding (not to mention 20).

I hope to have a huge win with Pharo business wise and be able to fund a serious team. That's my dream. I am actively working on it.

Pharo can stay relevant for that long I believe. I love the way it helps me think. I love the fact that I can look everywhere I want. I love the fact that this community has balls. I love to show the magic we can do with it. If it all goes nowhere, I do not even mind as I have a damn awesome time around here.

Now, I also want a working text model. This feels like a kind of psychological roadblock. Like a self sabotage. Let's put that dead rat on the table and make something about it.

I like Doru's Pillar editor. I guess the underlying engine will evolve to make it faster. Great. Grafoscopio will also be a driving force there I believe. Pharo can be superspeedy, no core problem.

Sorry for the rant.

Now back to promoting Pharo in front of Android/Angular/Java people this afternoon at http://devfest.be (note that this is the 3rd time I show Pharo/Amber there - they could kick me out but do not).

/Phil

On Fri, Oct 21, 2016 at 8:12 PM, Dimitris Chloupis <[hidden email]> wrote:

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 <[hidden email]> wrote:

On Oct 21, 2016, at 07:30, Norbert Hartl <[hidden email]> 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.

philippeback

Re: [ANN] Sparta v1.1

In reply to this post by Dale Henrichs-3

Dale,

I looked at the docs but it was kind of a hunt as they were a bit kind of everywhere.\

* Book chapters (Pharo). This including preversions with more info than the published one

* Google code wiki pages

* Github

* Other but can't even remember

Is there an official place for all things Metacello?

Metacello is great, especially with GTInspector so that we can see the directives etc.

Compared to Maven pom.xml / parent and nexus/artefactory repos, it is easier to deal with I'd say.

Phil

On Fri, Oct 21, 2016 at 10:15 PM, Dale Henrichs <[hidden email]> wrote:

On 10/21/2016 07:30 AM, Norbert Hartl wrote:

Dale,

Am 21.10.2016 um 16:12 schrieb Dale Henrichs <[hidden email]>:

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

kilon.alios

Re: [ANN] Sparta v1.1

In reply to this post by philippeback

Actually we dont, I am using the terminal to get and build my own images. Curl + use of startup scripts are more than enough. Simply , easy and straightforward. Pharo offers a super easy way to export any method as a command line argument. So there is literally no excuse.

Pharo already offers a metacello argument so you are set to go on installing anything you want through the terminal in your image and also offers evaluation of smalltalk code as argument. But I prefer startup scripts, I have made a startup script that can detect the name of images and install different packages to them, you can do insane things with startup scripts actually.

you can find my build setup here

https://github.com/kilon/makePharo

On Sat, Oct 22, 2016 at 10:06 AM [hidden email] <[hidden email]> wrote:

We need some easy to use gem-style installer on the command line.

Pharo is perfectly usable for any kind of project provided energy is poured in.

Things are in flux, yes, and it is frustrating not to have it all perfect. So what? If we weren't interested in wild things why would we be here after all?

Think long term: 10 years from now, improvements will have been massively compounding (not to mention 20).

I hope to have a huge win with Pharo business wise and be able to fund a serious team. That's my dream. I am actively working on it.

Pharo can stay relevant for that long I believe. I love the way it helps me think. I love the fact that I can look everywhere I want. I love the fact that this community has balls. I love to show the magic we can do with it. If it all goes nowhere, I do not even mind as I have a damn awesome time around here.

Now, I also want a working text model. This feels like a kind of psychological roadblock. Like a self sabotage. Let's put that dead rat on the table and make something about it.

I like Doru's Pillar editor. I guess the underlying engine will evolve to make it faster. Great. Grafoscopio will also be a driving force there I believe. Pharo can be superspeedy, no core problem.

Sorry for the rant.

Now back to promoting Pharo in front of Android/Angular/Java people this afternoon at http://devfest.be (note that this is the 3rd time I show Pharo/Amber there - they could kick me out but do not).

/Phil

On Fri, Oct 21, 2016 at 8:12 PM, Dimitris Chloupis <[hidden email]> wrote:
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 <[hidden email]> wrote:

On Oct 21, 2016, at 07:30, Norbert Hartl <[hidden email]> 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.

Thierry Goubier

Re: [ANN] Sparta v1.1

Hi Kilon,

2016-10-22 9:52 GMT+02:00 Dimitris Chloupis <[hidden email]>:

Actually we dont, I am using the terminal to get and build my own images. Curl + use of startup scripts are more than enough. Simply , easy and straightforward. Pharo offers a super easy way to export any method as a command line argument. So there is literally no excuse.

Pharo already offers a metacello argument so you are set to go on installing anything you want through the terminal in your image and also offers evaluation of smalltalk code as argument. But I prefer startup scripts, I have made a startup script that can detect the name of images and install different packages to them, you can do insane things with startup scripts actually.

Yes, that looks pretty cool.

I still stick with Makefiles and command line Pharo to build images, in part because when I run different projects, I can store inside the git of the project (i.e. version them) both the squeleton of the build environment and all the build instructions, instead of having to put a project-specific startup script inside a settings directory shared among all projects.

But I certainly see the value of running the startup scripts in the image in interactive mode, where it becomes a lot easier to debug them.

While running them on the command line is convenient too (make build, switch to email, reply, come back when the build is done).

you can find my build setup here

https://github.com/kilon/makePharo

I'll keep it in mind, thanks!

Thierry

On Sat, Oct 22, 2016 at 10:06 AM [hidden email] <[hidden email]> wrote:
We need some easy to use gem-style installer on the command line.

Pharo is perfectly usable for any kind of project provided energy is poured in.

Things are in flux, yes, and it is frustrating not to have it all perfect. So what? If we weren't interested in wild things why would we be here after all?

Think long term: 10 years from now, improvements will have been massively compounding (not to mention 20).

I hope to have a huge win with Pharo business wise and be able to fund a serious team. That's my dream. I am actively working on it.

Pharo can stay relevant for that long I believe. I love the way it helps me think. I love the fact that I can look everywhere I want. I love the fact that this community has balls. I love to show the magic we can do with it. If it all goes nowhere, I do not even mind as I have a damn awesome time around here.

Now, I also want a working text model. This feels like a kind of psychological roadblock. Like a self sabotage. Let's put that dead rat on the table and make something about it.

I like Doru's Pillar editor. I guess the underlying engine will evolve to make it faster. Great. Grafoscopio will also be a driving force there I believe. Pharo can be superspeedy, no core problem.

Sorry for the rant.

Now back to promoting Pharo in front of Android/Angular/Java people this afternoon at http://devfest.be (note that this is the 3rd time I show Pharo/Amber there - they could kick me out but do not).

/Phil

On Fri, Oct 21, 2016 at 8:12 PM, Dimitris Chloupis <[hidden email]> wrote:
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 <[hidden email]> wrote:

On Oct 21, 2016, at 07:30, Norbert Hartl <[hidden email]> 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.

kilon.alios

Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

it depends, the power that pharo offers is just massive on this department.

For example you say you dont like the idea of a global startup script, thats fine because you can have startup scripts per image, they go to the same folder as your image. If you really have a super complex setup it would make sense to make a git repo with just your make file and startup scripts. The makefile can be parameterized with command line arguments to perform diffirent installs then its a just a matter of copying the correct startup script to the folder with the appropriate image which of course is something the makefile can handle too.

Mariano has a great post on the subject of startup scripts which what I used to make my own

https://marianopeck.wordpress.com/2012/05/12/startuploader-running-startup-scripts-in-pharo/

By interactive mode again , I assume here you mean the GUI. Again it depends what you want to do, a pharo install comes with 2 executables pharo-ui which is the well known gui front and pharo which has no gui. In both cases you have debug abilities though I presume it would be easier to do this from inside a GUI. pharo and pharo-ui has an eval argument that allow you to execute any kind of code and there is also a save argument to save the image with your new code.

If you prefer GUI then you dont even need to pass metacello arguments, just make a configuration installing all your dependencies and put it in the STHUB metarepo corresponing to the version of pharo you use, it will be available from Package browser and you will be able to install all your dependencies with a single click every time you download a new install of pharo. Or just install a tool that you can use from playground to install the dependencies with a simple message. Or make a spec GUI or morphic GUI and do all that from the comfort of your mouse. OR.......

the options are just endless.

Another thing to remember here is that a baseline does not have to have one setup, you can have multiple setups installing things under diffirent conditions. Baseline also are aware of smalltalk implementation (squeak/ pharo) and pharo versions. That means diffirent installs under diffirent conditions and some deep fine tuning. Baseline also allow for actions before the install after the install, so even if you want to do some clean up you can do this also from the comfort of baseline.

Lastly but not least metacello is fully aware of git branches that gives you even more possibilities since a branch even in the same repo can be a completely new repo that gives you even more crazy options , since you can have diffirent Baseline under diffirent branch and of course the branch can contain its own code and assets (images, sounds , binary files, anything).

It really comes down to the way you like to work, pharo can do it, you choose how and what.

On Sat, Oct 22, 2016 at 11:37 AM Thierry Goubier <[hidden email]> wrote:

Hi Kilon,

2016-10-22 9:52 GMT+02:00 Dimitris Chloupis <[hidden email]>:
Actually we dont, I am using the terminal to get and build my own images. Curl + use of startup scripts are more than enough. Simply , easy and straightforward. Pharo offers a super easy way to export any method as a command line argument. So there is literally no excuse.

Pharo already offers a metacello argument so you are set to go on installing anything you want through the terminal in your image and also offers evaluation of smalltalk code as argument. But I prefer startup scripts, I have made a startup script that can detect the name of images and install different packages to them, you can do insane things with startup scripts actually.

Yes, that looks pretty cool.

I still stick with Makefiles and command line Pharo to build images, in part because when I run different projects, I can store inside the git of the project (i.e. version them) both the squeleton of the build environment and all the build instructions, instead of having to put a project-specific startup script inside a settings directory shared among all projects.

But I certainly see the value of running the startup scripts in the image in interactive mode, where it becomes a lot easier to debug them.

While running them on the command line is convenient too (make build, switch to email, reply, come back when the build is done).

you can find my build setup here

https://github.com/kilon/makePharo

I'll keep it in mind, thanks!

Thierry

On Sat, Oct 22, 2016 at 10:06 AM [hidden email] <[hidden email]> wrote:
We need some easy to use gem-style installer on the command line.

Pharo is perfectly usable for any kind of project provided energy is poured in.

Things are in flux, yes, and it is frustrating not to have it all perfect. So what? If we weren't interested in wild things why would we be here after all?

Think long term: 10 years from now, improvements will have been massively compounding (not to mention 20).

I hope to have a huge win with Pharo business wise and be able to fund a serious team. That's my dream. I am actively working on it.

Pharo can stay relevant for that long I believe. I love the way it helps me think. I love the fact that I can look everywhere I want. I love the fact that this community has balls. I love to show the magic we can do with it. If it all goes nowhere, I do not even mind as I have a damn awesome time around here.

Now, I also want a working text model. This feels like a kind of psychological roadblock. Like a self sabotage. Let's put that dead rat on the table and make something about it.

I like Doru's Pillar editor. I guess the underlying engine will evolve to make it faster. Great. Grafoscopio will also be a driving force there I believe. Pharo can be superspeedy, no core problem.

Sorry for the rant.

Now back to promoting Pharo in front of Android/Angular/Java people this afternoon at http://devfest.be (note that this is the 3rd time I show Pharo/Amber there - they could kick me out but do not).

/Phil

On Fri, Oct 21, 2016 at 8:12 PM, Dimitris Chloupis <[hidden email]> wrote:
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 <[hidden email]> wrote:

On Oct 21, 2016, at 07:30, Norbert Hartl <[hidden email]> 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.

philippeback

Re: [ANN] Sparta v1.1

In reply to this post by kilon.alios

I am having my (local) Jenkins CI do that for me.

There are several projects:

1/ P1: download fresh pharo

2/ P2: build "base worker" (an image with all prerequisites to dev) (takes a while: Seaside, Magritte, ....)

3/ P3: take recent commits from Git project and build an image based on the base worker one.

2 is taking a long time and if I did 2 and 3 it would be reallly long to ensure the final image is done.

Now, 3 takes only a few seconds, which allows to iterate fast (and as I keep a few artifacts back, save my ass at times)

Phil

On Sat, Oct 22, 2016 at 9:52 AM, Dimitris Chloupis <[hidden email]> wrote:

Actually we dont, I am using the terminal to get and build my own images. Curl + use of startup scripts are more than enough. Simply , easy and straightforward. Pharo offers a super easy way to export any method as a command line argument. So there is literally no excuse.

Pharo already offers a metacello argument so you are set to go on installing anything you want through the terminal in your image and also offers evaluation of smalltalk code as argument. But I prefer startup scripts, I have made a startup script that can detect the name of images and install different packages to them, you can do insane things with startup scripts actually.

you can find my build setup here

https://github.com/kilon/makePharo

On Sat, Oct 22, 2016 at 10:06 AM [hidden email] <[hidden email]> wrote:
We need some easy to use gem-style installer on the command line.

Pharo is perfectly usable for any kind of project provided energy is poured in.

Things are in flux, yes, and it is frustrating not to have it all perfect. So what? If we weren't interested in wild things why would we be here after all?

Think long term: 10 years from now, improvements will have been massively compounding (not to mention 20).

I hope to have a huge win with Pharo business wise and be able to fund a serious team. That's my dream. I am actively working on it.

Pharo can stay relevant for that long I believe. I love the way it helps me think. I love the fact that I can look everywhere I want. I love the fact that this community has balls. I love to show the magic we can do with it. If it all goes nowhere, I do not even mind as I have a damn awesome time around here.

Now, I also want a working text model. This feels like a kind of psychological roadblock. Like a self sabotage. Let's put that dead rat on the table and make something about it.

I like Doru's Pillar editor. I guess the underlying engine will evolve to make it faster. Great. Grafoscopio will also be a driving force there I believe. Pharo can be superspeedy, no core problem.

Sorry for the rant.

Now back to promoting Pharo in front of Android/Angular/Java people this afternoon at http://devfest.be (note that this is the 3rd time I show Pharo/Amber there - they could kick me out but do not).

/Phil

On Fri, Oct 21, 2016 at 8:12 PM, Dimitris Chloupis <[hidden email]> wrote:
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 <[hidden email]> wrote:

On Oct 21, 2016, at 07:30, Norbert Hartl <[hidden email]> 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.

kilon.alios

Re: [ANN] Sparta v1.1

Yeah it takes long because of pharo compilation, this is not different than python and ruby. Though python has pyc files which are compiled py files , unfortunately we dont have something similar out of the box. This is where the monolithic nature of the image file bite us back. I dont know if gems distributes the binary version of the source file, if they do , then yes gem has there the advantage of speed, if they dont, its the same situation.

Fuel does fit the job well in that department. Fuel files should be able to speed up your build process so massively that only your internet speed will be the bottleneck. Of course you will have to do the the export of pharo live code and date as fuel files but that is something your CI process can handle in the background. This means by the time you issue a rebuild or its issued auto magically because of webhook to a git commit, fuel files will be readily available and you will be able to reduce build time down to a minimal.

Fuel files give also the advantage of live data which will come handy for reproducing errors and fine tuning unit tests.

On Sat, Oct 22, 2016 at 12:15 PM [hidden email] <[hidden email]> wrote:

I am having my (local) Jenkins CI do that for me.

There are several projects:

1/ P1: download fresh pharo
2/ P2: build "base worker" (an image with all prerequisites to dev) (takes a while: Seaside, Magritte, ....)
3/ P3: take recent commits from Git project and build an image based on the base worker one.

2 is taking a long time and if I did 2 and 3 it would be reallly long to ensure the final image is done.

Now, 3 takes only a few seconds, which allows to iterate fast (and as I keep a few artifacts back, save my ass at times)

Phil

On Sat, Oct 22, 2016 at 9:52 AM, Dimitris Chloupis <[hidden email]> wrote:
Actually we dont, I am using the terminal to get and build my own images. Curl + use of startup scripts are more than enough. Simply , easy and straightforward. Pharo offers a super easy way to export any method as a command line argument. So there is literally no excuse.

Pharo already offers a metacello argument so you are set to go on installing anything you want through the terminal in your image and also offers evaluation of smalltalk code as argument. But I prefer startup scripts, I have made a startup script that can detect the name of images and install different packages to them, you can do insane things with startup scripts actually.

you can find my build setup here

https://github.com/kilon/makePharo

On Sat, Oct 22, 2016 at 10:06 AM [hidden email] <[hidden email]> wrote:
We need some easy to use gem-style installer on the command line.

Pharo is perfectly usable for any kind of project provided energy is poured in.

Things are in flux, yes, and it is frustrating not to have it all perfect. So what? If we weren't interested in wild things why would we be here after all?

Think long term: 10 years from now, improvements will have been massively compounding (not to mention 20).

I hope to have a huge win with Pharo business wise and be able to fund a serious team. That's my dream. I am actively working on it.

Pharo can stay relevant for that long I believe. I love the way it helps me think. I love the fact that I can look everywhere I want. I love the fact that this community has balls. I love to show the magic we can do with it. If it all goes nowhere, I do not even mind as I have a damn awesome time around here.

Now, I also want a working text model. This feels like a kind of psychological roadblock. Like a self sabotage. Let's put that dead rat on the table and make something about it.

I like Doru's Pillar editor. I guess the underlying engine will evolve to make it faster. Great. Grafoscopio will also be a driving force there I believe. Pharo can be superspeedy, no core problem.

Sorry for the rant.

Now back to promoting Pharo in front of Android/Angular/Java people this afternoon at http://devfest.be (note that this is the 3rd time I show Pharo/Amber there - they could kick me out but do not).

/Phil

On Fri, Oct 21, 2016 at 8:12 PM, Dimitris Chloupis <[hidden email]> wrote:
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 <[hidden email]> wrote:

On Oct 21, 2016, at 07:30, Norbert Hartl <[hidden email]> 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.

Thierry Goubier

Re: Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

In reply to this post by kilon.alios

Hi Kilon,

2016-10-22 10:56 GMT+02:00 Dimitris Chloupis <[hidden email]>:

it depends, the power that pharo offers is just massive on this department.

For example you say you dont like the idea of a global startup script, thats fine because you can have startup scripts per image, they go to the same folder as your image. If you really have a super complex setup it would make sense to make a git repo with just your make file and startup scripts. The makefile can be parameterized with command line arguments to perform diffirent installs then its a just a matter of copying the correct startup script to the folder with the appropriate image which of course is something the makefile can handle too.

Good point: the Makefile has to copy the startup script inside the image directory, if we keep that convention of building the new image inside a dedicated directory to be able to clean by rm -r that directory.

Mariano has a great post on the subject of startup scripts which what I used to make my own

https://marianopeck.wordpress.com/2012/05/12/startuploader-running-startup-scripts-in-pharo/

By interactive mode again , I assume here you mean the GUI. Again it depends what you want to do, a pharo install comes with 2 executables pharo-ui which is the well known gui front and pharo which has no gui. In both cases you have debug abilities though I presume it would be easier to do this from inside a GUI. pharo and pharo-ui has an eval argument that allow you to execute any kind of code and there is also a save argument to save the image with your new code.

Yes. I've been using eval in Makefiles for a few years now. I even prefer an eval Metacello new baseline: ... to the command line configuration loader, because I can use the standard Smalltalk syntax with eval (and Metacello) whereas I need to read the doc for the configuration command line handler.

I even have a 'deployment' version for external partners, where the Makefile detect it is started from an archive extracted from git and not the original git repo, and switches to filetree (and loading different packages) to build the image.

If you prefer GUI then you dont even need to pass metacello arguments, just make a configuration installing all your dependencies and put it in the STHUB metarepo corresponing to the version of pharo you use, it will be available from Package browser and you will be able to install all your dependencies with a single click every time you download a new install of pharo. Or just install a tool that you can use from playground to install the dependencies with a simple message. Or make a spec GUI or morphic GUI and do all that from the comfort of your mouse. OR.......

the options are just endless.

Yes. Oh well, in fact the metarepo thing doesnt work well with Pharo5 and Pharo6, as one of the user of the GitFileTree configuration discovered a week or two ago. If you are using Pharo5, a configuration in the Pharo6 metarepo will override the one in the Pharo5 metarepo.

Another thing to remember here is that a baseline does not have to have one setup, you can have multiple setups installing things under diffirent conditions. Baseline also are aware of smalltalk implementation (squeak/ pharo) and pharo versions. That means diffirent installs under diffirent conditions and some deep fine tuning. Baseline also allow for actions before the install after the install, so even if you want to do some clean up you can do this also from the comfort of baseline.

Lastly but not least metacello is fully aware of git branches that gives you even more possibilities since a branch even in the same repo can be a completely new repo that gives you even more crazy options , since you can have diffirent Baseline under diffirent branch and of course the branch can contain its own code and assets (images, sounds , binary files, anything).

Yes,

Thierry

It really comes down to the way you like to work, pharo can do it, you choose how and what.

On Sat, Oct 22, 2016 at 11:37 AM Thierry Goubier <[hidden email]> wrote:
Hi Kilon,

2016-10-22 9:52 GMT+02:00 Dimitris Chloupis <[hidden email]>:
Actually we dont, I am using the terminal to get and build my own images. Curl + use of startup scripts are more than enough. Simply , easy and straightforward. Pharo offers a super easy way to export any method as a command line argument. So there is literally no excuse.

Pharo already offers a metacello argument so you are set to go on installing anything you want through the terminal in your image and also offers evaluation of smalltalk code as argument. But I prefer startup scripts, I have made a startup script that can detect the name of images and install different packages to them, you can do insane things with startup scripts actually.

Yes, that looks pretty cool.

I still stick with Makefiles and command line Pharo to build images, in part because when I run different projects, I can store inside the git of the project (i.e. version them) both the squeleton of the build environment and all the build instructions, instead of having to put a project-specific startup script inside a settings directory shared among all projects.

But I certainly see the value of running the startup scripts in the image in interactive mode, where it becomes a lot easier to debug them.

While running them on the command line is convenient too (make build, switch to email, reply, come back when the build is done).

you can find my build setup here

https://github.com/kilon/makePharo

I'll keep it in mind, thanks!

Thierry

On Sat, Oct 22, 2016 at 10:06 AM [hidden email] <[hidden email]> wrote:
We need some easy to use gem-style installer on the command line.

Pharo is perfectly usable for any kind of project provided energy is poured in.

Things are in flux, yes, and it is frustrating not to have it all perfect. So what? If we weren't interested in wild things why would we be here after all?

Think long term: 10 years from now, improvements will have been massively compounding (not to mention 20).

I hope to have a huge win with Pharo business wise and be able to fund a serious team. That's my dream. I am actively working on it.

Pharo can stay relevant for that long I believe. I love the way it helps me think. I love the fact that I can look everywhere I want. I love the fact that this community has balls. I love to show the magic we can do with it. If it all goes nowhere, I do not even mind as I have a damn awesome time around here.

Now, I also want a working text model. This feels like a kind of psychological roadblock. Like a self sabotage. Let's put that dead rat on the table and make something about it.

I like Doru's Pillar editor. I guess the underlying engine will evolve to make it faster. Great. Grafoscopio will also be a driving force there I believe. Pharo can be superspeedy, no core problem.

Sorry for the rant.

Now back to promoting Pharo in front of Android/Angular/Java people this afternoon at http://devfest.be (note that this is the 3rd time I show Pharo/Amber there - they could kick me out but do not).

/Phil

On Fri, Oct 21, 2016 at 8:12 PM, Dimitris Chloupis <[hidden email]> wrote:
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 <[hidden email]> wrote:

On Oct 21, 2016, at 07:30, Norbert Hartl <[hidden email]> 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.

Aliaksei Syrel

Re: [ANN] Sparta v1.1

In reply to this post by Dale Henrichs-3

MozServices crash is intentional!
When you load Sparta using metacello it runs installer scripts and automatically starts services. But they are already running if you have Sparta installed.

I need to find a pretty solution for it. Actually it is complicated. Services can not just stop while image is running, because rendering would instantly crash. Imagine if Bloc is running on Sparta, playground is rendered on Sparta. And now you stop services to update. What should happen? :)

Just take fresh image. I will add an assertion to forbid Sparta installation if it is already installed.

Cheers
Alex

On Oct 22, 2016 2:09 AM, "Dale Henrichs" <[hidden email]> wrote:

Right, but since there are known bugs in Sierra perhaps MozServices is hitting one of them.

In our case we hit a bug in poll() which is a bit surprising and apparently the bug is hitting Apple's own curl implementation -- see discussion here[1]...

Dale

[1] https://github.com/curl/curl/issues/1057

On 10/21/2016 04:56 PM, Denis Kudriashov wrote:

Hi Dale

2016-10-22 1:20 GMT+02:00 Dale Henrichs <[hidden email]>:

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)

Aliaksei Syrel

Re: [ANN] Sparta v1.1

I use plugin for months and never had a single random crash :)
It is very stable

On Oct 22, 2016 11:55 AM, "Aliaksei Syrel" <[hidden email]> wrote:

MozServices crash is intentional!
When you load Sparta using metacello it runs installer scripts and automatically starts services. But they are already running if you have Sparta installed.

I need to find a pretty solution for it. Actually it is complicated. Services can not just stop while image is running, because rendering would instantly crash. Imagine if Bloc is running on Sparta, playground is rendered on Sparta. And now you stop services to update. What should happen? :)

Just take fresh image. I will add an assertion to forbid Sparta installation if it is already installed.

Cheers
Alex

On Oct 22, 2016 2:09 AM, "Dale Henrichs" <[hidden email]> wrote:

Right, but since there are known bugs in Sierra perhaps MozServices is hitting one of them.

In our case we hit a bug in poll() which is a bit surprising and apparently the bug is hitting Apple's own curl implementation -- see discussion here[1]...

Dale

[1] https://github.com/curl/curl/issues/1057

On 10/21/2016 04:56 PM, Denis Kudriashov wrote:

Hi Dale

2016-10-22 1:20 GMT+02:00 Dale Henrichs <[hidden email]>:

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)

kilon.alios

Re: Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

In reply to this post by Thierry Goubier

Didn't Esteban fixed metarepo ? I think I remember him saying that he did.

Don't know how heavy and complex your setup is but if I was in a situation where the building process became to complex with several builds at the same time , I think as Phil said a CI would have been more handy. Its what we use for a vast array of custom images. Obviously you could make your own command line tool with Pharo. An image dedicated to building your own images , you alias the Pharo executable passed the image name to any name that make it look as if it is a bash command or bash utility.

For example

Pharo-build gitfiletree ./filetree -replace -stable -runTests

On Sat, 22 Oct 2016 at 12:34, Thierry Goubier <[hidden email]> wrote:

Hi Kilon,

2016-10-22 10:56 GMT+02:00 Dimitris Chloupis <[hidden email]>:
it depends, the power that pharo offers is just massive on this department.

For example you say you dont like the idea of a global startup script, thats fine because you can have startup scripts per image, they go to the same folder as your image. If you really have a super complex setup it would make sense to make a git repo with just your make file and startup scripts. The makefile can be parameterized with command line arguments to perform diffirent installs then its a just a matter of copying the correct startup script to the folder with the appropriate image which of course is something the makefile can handle too.

Good point: the Makefile has to copy the startup script inside the image directory, if we keep that convention of building the new image inside a dedicated directory to be able to clean by rm -r that directory.

Mariano has a great post on the subject of startup scripts which what I used to make my own

https://marianopeck.wordpress.com/2012/05/12/startuploader-running-startup-scripts-in-pharo/

By interactive mode again , I assume here you mean the GUI. Again it depends what you want to do, a pharo install comes with 2 executables pharo-ui which is the well known gui front and pharo which has no gui. In both cases you have debug abilities though I presume it would be easier to do this from inside a GUI. pharo and pharo-ui has an eval argument that allow you to execute any kind of code and there is also a save argument to save the image with your new code.

Yes. I've been using eval in Makefiles for a few years now. I even prefer an eval Metacello new baseline: ... to the command line configuration loader, because I can use the standard Smalltalk syntax with eval (and Metacello) whereas I need to read the doc for the configuration command line handler.

I even have a 'deployment' version for external partners, where the Makefile detect it is started from an archive extracted from git and not the original git repo, and switches to filetree (and loading different packages) to build the image.

If you prefer GUI then you dont even need to pass metacello arguments, just make a configuration installing all your dependencies and put it in the STHUB metarepo corresponing to the version of pharo you use, it will be available from Package browser and you will be able to install all your dependencies with a single click every time you download a new install of pharo. Or just install a tool that you can use from playground to install the dependencies with a simple message. Or make a spec GUI or morphic GUI and do all that from the comfort of your mouse. OR.......

the options are just endless.

Yes. Oh well, in fact the metarepo thing doesnt work well with Pharo5 and Pharo6, as one of the user of the GitFileTree configuration discovered a week or two ago. If you are using Pharo5, a configuration in the Pharo6 metarepo will override the one in the Pharo5 metarepo.

Another thing to remember here is that a baseline does not have to have one setup, you can have multiple setups installing things under diffirent conditions. Baseline also are aware of smalltalk implementation (squeak/ pharo) and pharo versions. That means diffirent installs under diffirent conditions and some deep fine tuning. Baseline also allow for actions before the install after the install, so even if you want to do some clean up you can do this also from the comfort of baseline.

Lastly but not least metacello is fully aware of git branches that gives you even more possibilities since a branch even in the same repo can be a completely new repo that gives you even more crazy options , since you can have diffirent Baseline under diffirent branch and of course the branch can contain its own code and assets (images, sounds , binary files, anything).

Yes,

Thierry

It really comes down to the way you like to work, pharo can do it, you choose how and what.

On Sat, Oct 22, 2016 at 11:37 AM Thierry Goubier <[hidden email]> wrote:
Hi Kilon,

2016-10-22 9:52 GMT+02:00 Dimitris Chloupis <[hidden email]>:
Actually we dont, I am using the terminal to get and build my own images. Curl + use of startup scripts are more than enough. Simply , easy and straightforward. Pharo offers a super easy way to export any method as a command line argument. So there is literally no excuse.

Pharo already offers a metacello argument so you are set to go on installing anything you want through the terminal in your image and also offers evaluation of smalltalk code as argument. But I prefer startup scripts, I have made a startup script that can detect the name of images and install different packages to them, you can do insane things with startup scripts actually.

Yes, that looks pretty cool.

I still stick with Makefiles and command line Pharo to build images, in part because when I run different projects, I can store inside the git of the project (i.e. version them) both the squeleton of the build environment and all the build instructions, instead of having to put a project-specific startup script inside a settings directory shared among all projects.

But I certainly see the value of running the startup scripts in the image in interactive mode, where it becomes a lot easier to debug them.

While running them on the command line is convenient too (make build, switch to email, reply, come back when the build is done).

you can find my build setup here

https://github.com/kilon/makePharo

I'll keep it in mind, thanks!

Thierry

On Sat, Oct 22, 2016 at 10:06 AM [hidden email] <[hidden email]> wrote:
We need some easy to use gem-style installer on the command line.

Pharo is perfectly usable for any kind of project provided energy is poured in.

Things are in flux, yes, and it is frustrating not to have it all perfect. So what? If we weren't interested in wild things why would we be here after all?

Think long term: 10 years from now, improvements will have been massively compounding (not to mention 20).

I hope to have a huge win with Pharo business wise and be able to fund a serious team. That's my dream. I am actively working on it.

Pharo can stay relevant for that long I believe. I love the way it helps me think. I love the fact that I can look everywhere I want. I love the fact that this community has balls. I love to show the magic we can do with it. If it all goes nowhere, I do not even mind as I have a damn awesome time around here.

Now, I also want a working text model. This feels like a kind of psychological roadblock. Like a self sabotage. Let's put that dead rat on the table and make something about it.

I like Doru's Pillar editor. I guess the underlying engine will evolve to make it faster. Great. Grafoscopio will also be a driving force there I believe. Pharo can be superspeedy, no core problem.

Sorry for the rant.

Now back to promoting Pharo in front of Android/Angular/Java people this afternoon at http://devfest.be (note that this is the 3rd time I show Pharo/Amber there - they could kick me out but do not).

/Phil

On Fri, Oct 21, 2016 at 8:12 PM, Dimitris Chloupis <[hidden email]> wrote:
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 <[hidden email]> wrote:

On Oct 21, 2016, at 07:30, Norbert Hartl <[hidden email]> 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.

EstebanLM

Re: Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

In reply to this post by kilon.alios

On 22 Oct 2016, at 10:56, Dimitris Chloupis <[hidden email]> wrote:

We need some easy to use gem-style installer on the command line.

we have it:

./pharo Pharo.image get Seaside3

will load seaside into your Pharo.image

this is catalog based, of course (there is no magic there, if you want an easy way to install things, you need a centralised repository).

Esteban

ps: there are a lot of perks like that people ignores… what we actually need is a better documentation system :)

EstebanLM

Re: Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

In reply to this post by kilon.alios

On 22 Oct 2016, at 12:00, Dimitris Chloupis <[hidden email]> wrote:

Didn't Esteban fixed metarepo ? I think I remember him saying that he did.

fixed in what sense?

Esteban

kilon.alios

Re: Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

I was replying to Thierry saying that we had issues with Pharo mixing metarepo6 with metarepo5

On Sat, 22 Oct 2016 at 13:11, Esteban Lorenzano <[hidden email]> wrote:

On 22 Oct 2016, at 12:00, Dimitris Chloupis <[hidden email]> wrote:

Didn't Esteban fixed metarepo ? I think I remember him saying that he did.

fixed in what sense?

Esteban

Aliaksei Syrel

Re: [ANN] Sparta v1.1

In reply to this post by Denis Kudriashov

As Doru already mentioned text editor is an important part of the tools. There are some requirements a text editor should fulfil.

Support of large files ( >> 100mb)
Support of large pieces of text located in memory
Allow developers to embed visual elements (pictures, interactive elements, custom elements)
Support of more sophisticated layouts rather than line-based. For example columns.
Line breaking
Text wrapping
Hyphens
Should be fast

Tests show that TxText model is very nice for basic cases, works well for "normal" use.

However, when it comes to extreme cases linked list of spans just fails, while rope shows great performance - and it also scales.

Cheers,

Alex

On 19 October 2016 at 23:51, Denis Kudriashov <[hidden email]> wrote:

2016-10-19 18:06 GMT+02:00 Aliaksei Syrel <[hidden email]>:
- Added initial text support, for instance rendering and high precision measurement.

I look at code and it seems you implemented another one new text model? Why you not use TxText?

123456