[ANN] Sparta v1.1
Locked
 
|
On Thu, Oct 20, 2016 at 9:07 AM, Aliaksei Syrel <[hidden email]> wrote:
Yeah but none of the libs (Cairo, Pixman, FreeType) are required to run Pharo, they're required only if you use them. I compile VMs without such libraires and Pharo works just fine as a development environment and for simple things like web servers. The Squeak VM for example have around 2Mb footprint in total, including 1Mb for the C runtime (initialized and uninitialized data, executable code) and 1 Mb for the machine code zone and can run most Pharo features just fine, including for examples web services and the IDE. Right now the VM cannot start completely headless, the headless mode just hides the main window, so if the main window start-up depends on Sparta, it's not possible to run Pharo headless without many Mb of memory footprint. Which leads the first question... >> Is it possible to start your Bloc Pharo image on a 2Mb footprint VM ? By asking this question, I imply, if there is no Cairo/Pixman/FreeType/Sparta plugin, can the image run headless and can it run UI applications ? The last problem is that Pharo can currently run UI application like the IDE on a 2Mb memory footprint VM. Let's assume Pharo with Bloc/Sparta/etc. can be run either headless on a 2Mb memory footprint VM or with a UI on a 7Mb+ memory footprint VM. It means now people doing UI would need extra memory, for example, in the case of android deployment where the android app includes the VM and the image, the app memory consumption at runtime would be at least 5Mb bigger. >> Is the community ok with this or will we need to maintain both the Sparta back-end and a Bloc to BitBlt back-end as a fall-back to run on smaller VMs ?
|
|
|
In reply to this post by Sean P. DeNigris
> On Oct 21, 2016, at 4:00 AM, Sean P. DeNigris <[hidden email]> wrote: > > Denis Kudriashov wrote >> I look at code and it seems you implemented another one new text model? >> Why >> you not use TxText? > > Argh. I know it's bad form to complain about gifts, A bit :). > but at the rate we > reinvent the wheel, I often fear that I will be retired from programming > before we have a sane text model :/ 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). Alex will follow up with a more technical comparison between the current approach and the one from TxText. Doru > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/ANN-Sparta-v1-1-tp4919394p4919570.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- www.tudorgirba.com www.feenk.com "There are no old things, there are only old ways of looking at them." |
|
|
In reply to this post by NorbertHartl
Norbert, It is also called evolution ... with each step forward new
possibilities are revealed and often the old (current) way of
doing things needs to change to better leverage these new
possibilities ... and evolution is required[4]. Change is also painful and keeping up with an ever-changing system takes a lot of individual effort. If you don't want to deal with change, then pick a Pharo version and stick with it ... Pharo3.0 is still functional and I for one make sure that all new versions of Metacello work on older versions of Squeak, Pharo and GemStone[1] --- but you don't have to use the newer version of Metacello if you don't want to:). I use Pharo3.0 on a daily basis for tODE -- I decided that I
wanted to spend my time evolving and changing tODE itself rather
than spend a portion of every year porting to a newer version of
Pharo. Fortunately I don't NEED the fancy new widgets in Pharo3.0
to make progress with tODE. Metacello is not the only project to ensure that it continues to
function on older versions of Pharo. Seaside[2], Voyage[3] and I'm
sure others make an effort to continue to function on older
versions of Pharo --- the technology exists for maintaining
compatibility with older versions of Pharo for those projects that
aren't making the effort now. Dale [1] https://travis-ci.org/dalehenrich/metacello-work/builds/168940183 [2] https://travis-ci.org/SeasideSt/Seaside/builds/160382244 [3] https://travis-ci.org/pharo-nosql/voyage/builds/167012791 [4] https://en.wikipedia.org/wiki/Software_evolution On 10/21/16 12:10 AM, Norbert Hartl
wrote:
|
|
|
In reply to this post by Clément Béra
Hi Clement,
Thanks for raising this question. In short, Sparta is inspired from Athens and it has a similar structure. So, there is an in-image interface of the canvas, and there is a concrete implementation through the plugin (based on Moz2D). To target a completely in-image rendering, it is certainly possible to implement a BitBlt backend of the Sparta canvas. To implement this part, we would need help. The goal is indeed to have only one canvas in the default Pharo distribution: Sparta. However, this will not happen suddenly. Ideally, when Pharo 6 will be released, there will be a beta version of Sparta + Bloc + some tools that will be loadable externally. Then my guess is that it will still take another year until we get the full development environment working on top of Sparta. So, it is to be expected that this transition will take at least 1.5 years during which time Athens will still provide the option of running on top of BitBlt. Does this answer the concern? But, now my question: Would it not be possible to get the VM to not open a window when in headless mode? Cheers, Doru > On Oct 21, 2016, at 2:23 PM, Clément Bera <[hidden email]> wrote: > > > > On Thu, Oct 20, 2016 at 9:07 AM, Aliaksei Syrel <[hidden email]> wrote: > Hi Stéphane > > Indeed, build is broken :) > Yesterday I took a very brief look at bloc and can confirm that development version is loadable in Pharo 6 and is completely Sparta based. (all examples work for me) > > You are right, live environment on embedded systems is great goal to achieve. Sparta must not prevent pharo from getting there. It is true that plugin is relatively big (windows 7mb, osx 15mb, linux 18mb). However, it is all-in-one build and size can be reduced dramatically. > > As I understand, Pharo for PC should not make any assumptions about user's hardware. If gpu accelerated backend can not be used there should be still a performant fallback backend which also needs a fallback that is guaranteed to work even on Personal Calculators. (Taschenrechner). That is why library is so big. For example for mac and windows Sparta is shipped with 3 (!) backends that together build fallback chain, for instance on windows: direct2d1.1, skia, cairo. Compiling library for mac without Skia reduces binary size from 15mb to 10mb. Removing GL package and leaving only software backends may reduce size even more. > > It is a bit different on embedded systems, since hardware configuration is already known and there is no need to have so many fallback backends. Library itself allows developers to add new exotic backends quite easily. > > Let's take Pharo6 for mac. It is shipped with the following libs: > Cairo (1.4mb) + Pixman (2.8mb) + Freetype (0.8mb) = 5mb > > Moz2D is self contained and does not require any additional libs. > Moz2D = 15mb, Moz2D without Skia = 10mb. Moz2D without Skia and GL = ? (estimate around 6-7mb). > > As you can see we get almost the same numbers :) > > Yeah but none of the libs (Cairo, Pixman, FreeType) are required to run Pharo, they're required only if you use them. I compile VMs without such libraires and Pharo works just fine as a development environment and for simple things like web servers. The Squeak VM for example have around 2Mb footprint in total, including 1Mb for the C runtime (initialized and uninitialized data, executable code) and 1 Mb for the machine code zone and can run most Pharo features just fine, including for examples web services and the IDE. > > Right now the VM cannot start completely headless, the headless mode just hides the main window, so if the main window start-up depends on Sparta, it's not possible to run Pharo headless without many Mb of memory footprint. > > Which leads the first question... > > >> Is it possible to start your Bloc Pharo image on a 2Mb footprint VM ? By asking this question, I imply, if there is no Cairo/Pixman/FreeType/Sparta plugin, can the image run headless and can it run UI applications ? > > The last problem is that Pharo can currently run UI application like the IDE on a 2Mb memory footprint VM. Let's assume Pharo with Bloc/Sparta/etc. can be run either headless on a 2Mb memory footprint VM or with a UI on a 7Mb+ memory footprint VM. It means now people doing UI would need extra memory, for example, in the case of android deployment where the android app includes the VM and the image, the app memory consumption at runtime would be at least 5Mb bigger. > > >> Is the community ok with this or will we need to maintain both the Sparta back-end and a Bloc to BitBlt back-end as a fall-back to run on smaller VMs ? > > > Cheers > Alex > > On Oct 19, 2016 22:16, "stepharo" <[hidden email]> wrote: > Hi Aliaksei > > It looks gorgeous. > I tried to launch the Bloc image from the CI and it crashes during startup on my mac. I reported that to Glenn and Alain but so far I simply cannot see Bloc code. Is it working for you? I mean is it me that is using the wrong VM. > > Then I have a question: > > - do you think that we can have a fallback in terms of back end for the case where we could like to run Pharo on coffee machines but get a live environment on such machines? This is related to the discussions we got this summer about the memory footprint that Moz2D will put on us. > > I do not mean that we must have one but I think that this is important to check because we can say that Pharo is small but if we need 20 mb libraries for rendering there are some cases where this can kill its usage. > > Stef > > Le 19/10/16 à 18:06, Aliaksei Syrel a écrit : >> Hi >> >> I am happy to announce the release of Sparta v1.1 for Pharo 6. >> https://github.com/syrel/Sparta/tree/v1.1 >> >> It can be bootstrapped with the following script: >> >> Metacello new >> >> >> baseline: 'Sparta' >> ; >> >> repository: 'github://syrel/sparta:v1.1/src' >> ; >> >> load: #file:core >> Examples are on class side of: MozExamples, MozTextExamples >> (for linux users: if you use 32bit pharo on 64bit linux, sparta will not work, since 32bit plugin depends on 32bit GTK which conflicts with 64bit GTK. Either use 32bit linux or 64bit pharo. I tested sparta with 64bit vm on mac and linux - it works, but some features fail because FFI is not ready) >> Release of v1.1 is focused on hardware acceleration, windows support and text rendering. >> What is new: >> - Default backends on all platforms changed from software to hardware accelerated. >> - Now also works on Windows! Default backend is Direct2D for drawings and DirectWrite for text. On multi-gpu machines per-app-default setting is respected. In case of Nvidia it can be changed in nvidia control panel. Sparta is x2 faster on discrete gpu than on integrated one. >> - Added initial text support, for instance rendering and high precision measurement. >> - Per-platform settings system is now image based. Allows to enable/disable hardware acceleration, change default backends, change font-mappings tables. >> Some text examples: >> (rendering) >> <Mail Attachment.png> >> (measurement) >> <Mail Attachment.png> >> Cheers, >> Alex -- www.tudorgirba.com www.feenk.com "There are no old things, there are only old ways of looking at them." |
|
|
In reply to this post by Dale Henrichs-3
Dale,
I was not arguing against evolution. I was refering to the fact that work of others is mostly ignored just to come up with a potential weaker solution. Norbert
|
|
|
In reply to this post by Tudor Girba-2
2016-10-21 15:21 GMT+02:00 Tudor Girba <[hidden email]>: > but at the rate we 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? |
|
|
In reply to this post by NorbertHartl
Hi Norbert,
It is not ignored at all. Cheers, Doru > On Oct 21, 2016, at 3:50 PM, Norbert Hartl <[hidden email]> wrote: > > Dale, > > I was not arguing against evolution. I was refering to the fact that work of others is mostly ignored just to come up with a potential weaker solution. > > Norbert > >> Am 21.10.2016 um 15:34 schrieb Dale Henrichs <[hidden email]>: >> >> Norbert, >> >> It is also called evolution ... with each step forward new possibilities are revealed and often the old (current) way of doing things needs to change to better leverage these new possibilities ... and evolution is required[4]. >> Change is also painful and keeping up with an ever-changing system takes a lot of individual effort. >> >> If you don't want to deal with change, then pick a Pharo version and stick with it ... Pharo3.0 is still functional and I for one make sure that all new versions of Metacello work on older versions of Squeak, Pharo and GemStone[1] --- but you don't have to use the newer version of Metacello if you don't want to:). >> >> I use Pharo3.0 on a daily basis for tODE -- I decided that I wanted to spend my time evolving and changing tODE itself rather than spend a portion of every year porting to a newer version of Pharo. Fortunately I don't NEED the fancy new widgets in Pharo3.0 to make progress with tODE. >> Metacello is not the only project to ensure that it continues to function on older versions of Pharo. Seaside[2], Voyage[3] and I'm sure others make an effort to continue to function on older versions of Pharo --- the technology exists for maintaining compatibility with older versions of Pharo for those projects that aren't making the effort now. >> If you choose to leverage the benefits of the newer versions of Pharo, then you must accept the cost, but you can pace yourself if the rate of change becomes too much. >> >> Dale >> [1] https://travis-ci.org/dalehenrich/metacello-work/builds/168940183 >> >> [2] https://travis-ci.org/SeasideSt/Seaside/builds/160382244 >> >> [3] https://travis-ci.org/pharo-nosql/voyage/builds/167012791 >> [4] https://en.wikipedia.org/wiki/Software_evolution >> >> On 10/21/16 12:10 AM, Norbert Hartl wrote: >>> >>> >>> Am 21.10.2016 um 04:00 schrieb Sean P. DeNigris <[hidden email]>: >>> >>>> Denis Kudriashov wrote >>>>> I look at code and it seems you implemented another one new text model? >>>>> Why >>>>> you not use TxText? >>>> >>>> Argh. I know it's bad form to complain about gifts, but at the rate we >>>> reinvent the wheel, I often fear that I will be retired from programming >>>> before we have a sane text model :/ >>>> >>> It has a name and we should fight it: >>> >>> https://en.m.wikipedia.org/wiki/Not_invented_here >>> >>> Norbert >>>> >>>> ----- >>>> Cheers, >>>> Sean >>>> -- >>>> View this message in context: http://forum.world.st/ANN-Sparta-v1-1-tp4919394p4919570.html >>>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >>>> >> > -- www.tudorgirba.com www.feenk.com "Some battles are better lost than fought." |
|
|
In reply to this post by NorbertHartl
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:). Dale On 10/21/16 6:50 AM, Norbert Hartl
wrote:
Dale, |
|
|
In reply to this post by Denis Kudriashov
Hi,
> On Oct 21, 2016, at 3:55 PM, Denis Kudriashov <[hidden email]> wrote: > > > 2016-10-21 15:21 GMT+02:00 Tudor Girba <[hidden email]>: > > but at the rate we > > reinvent the wheel, I often fear that I will be retired from programming > > before we have a sane text model :/ > > 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). As to the importance of a moldable text editor that also scales properly, I disagree with you. We need an infrastructure on top of which we can build the next 5 years of tools. Especially in the context of GT, the goal is not to reproduce the existing tools, but to create completely new ones that are not possible right now, and a scalable & moldable text editor and model is a key component for what we want to do next. That is why we will invest the effort in this part. We might fail in the process, but then again we might succeed. We can only invent a new future if we first dream of it, and then try :). Doru -- www.tudorgirba.com www.feenk.com “Software has no shape. Actually, it has no one shape. It has many." |
|
|
In reply to this post by Dale Henrichs-3
I think that the concept of a LTS will become useful at one point. Like, every 3 versions or so. On Fri, Oct 21, 2016 at 4:12 PM, Dale Henrichs <[hidden email]> wrote:
|
|
|
In reply to this post by Tudor Girba-2
2016-10-21 16:15 GMT+02:00 Tudor Girba <[hidden email]>:
If it is done then no complains from me. It is super cool. |
|
|
In reply to this post by Tudor Girba-2
On Fri, Oct 21, 2016 at 3:41 PM, Tudor Girba <[hidden email]> wrote: Hi Clement, It does. I understand a BitBlt back-end is possible to have UI applications running on a low memory footprint runtime. Now the question the community should answer is if we want to implement and maintain that back-end or not.
I would love to see that. It's theoretically possible, it's just a matter of doing it and integrating it while it's time-consuming. I believe there was some work in that direction as part of the SDL / OSWindow work. If the community wants to move to Sparta and does not care if the memory footprint is increased by 5 Mb for non headless application, it may make sense to invest in that direction instead of the implementation and maintenance of a BitBlt based back-end.
|
|
|
In reply to this post by Dale Henrichs-3
Dale,
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/> Norbert
|
|
Administrator
|
In reply to this post by Tudor Girba-2
I really appreciate your long-term vision. My point/concern is that IMHO the most important thing is to "rachet up" - to alternate frequently between: a) releasing working versions of current best ideas (the many benefits of which include locking in progress, getting feedback from a wide audience, and getting buy-in/allowing users to adapt), and b) using that as a launching point for new experiments We are still using the same original awful text model that has stymied so many users/projects! Let's focus on and release something useable - anything - to take the pressure off while we invent the future. To illustrate the general principal, think about all the pain we have experienced because the last (promised) crucial step of cleaning and refactoring Squeak was not accomplished before beginning the next experiment! My question is: where is the sweet spot between the zero vision (but universal accessibility for actual work) of Java/C++, and infinite vision (at the extreme cost of immediately-usable artifacts) of Squeak/VPRI[1]? 1. This is not a criticism; they are just in a different business (cathedral building)
Cheers,
Sean |
|
|
In reply to this post by NorbertHartl
now you are going to complain also for the dark theme? come on! ;)
|
|
|
In reply to this post by Sean P. DeNigris
> On 21 Oct 2016, at 16:43, Sean P. DeNigris <[hidden email]> wrote: > > Tudor Girba-2 wrote >> I would kindly ask for patience. What is perhaps less clear is that this >> editor is in the critical path of the GT project and we are committed to >> deliver an editor that actually works. We are still investigating >> different paths, both on the low level (like with Rope) and at the higher >> level (like how to organize the layout). > > I really appreciate your long-term vision. My point/concern is that IMHO the > most important thing is to "rachet up" - to alternate frequently between: > a) releasing working versions of current best ideas (the many benefits of > which include locking in progress, getting feedback from a wide audience, > and getting buy-in/allowing users to adapt), and > b) using that as a launching point for new experiments > > We are still using the same original awful text model that has stymied so > many users/projects! Let's focus on and release something useable - anything > - to take the pressure off while we invent the future. > > To illustrate the general principal, think about all the pain we have > experienced because the last (promised) crucial step of cleaning and > refactoring Squeak was not accomplished before beginning the next > experiment! My question is: where is the sweet spot between the zero vision > (but universal accessibility for actual work) of Java/C++, and infinite > vision (at the extreme cost of immediately-usable artifacts) of > Squeak/VPRI[1]? amen. think is: is like the third time we start once again to build the next huge steps. and frankly, while waiting for that we have a text model that sucks and a cool text model unfinished and usable and a text editor that cannot handle complicated stuff because it is not ready, etc. etc. it feels bad. it tastes bad. and is not good at all. Esteban > > 1. This is not a criticism; they are just in a different business (cathedral > building) > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/ANN-Sparta-v1-1-tp4919394p4919647.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > |
Re: [ANN] Sparta v1.1
|
|
> On 21 Oct 2016, at 17:19, Esteban Lorenzano <[hidden email]> wrote: > >> >> On 21 Oct 2016, at 16:43, Sean P. DeNigris <[hidden email]> wrote: >> >> Tudor Girba-2 wrote >>> I would kindly ask for patience. What is perhaps less clear is that this >>> editor is in the critical path of the GT project and we are committed to >>> deliver an editor that actually works. We are still investigating >>> different paths, both on the low level (like with Rope) and at the higher >>> level (like how to organize the layout). >> >> I really appreciate your long-term vision. My point/concern is that IMHO the >> most important thing is to "rachet up" - to alternate frequently between: >> a) releasing working versions of current best ideas (the many benefits of >> which include locking in progress, getting feedback from a wide audience, >> and getting buy-in/allowing users to adapt), and >> b) using that as a launching point for new experiments >> >> We are still using the same original awful text model that has stymied so >> many users/projects! Let's focus on and release something useable - anything >> - to take the pressure off while we invent the future. >> >> To illustrate the general principal, think about all the pain we have >> experienced because the last (promised) crucial step of cleaning and >> refactoring Squeak was not accomplished before beginning the next >> experiment! My question is: where is the sweet spot between the zero vision >> (but universal accessibility for actual work) of Java/C++, and infinite >> vision (at the extreme cost of immediately-usable artifacts) of >> Squeak/VPRI[1]? > > amen. > > think is: is like the third time we start once again to build the next huge steps. > and frankly, while waiting for that we have a text model that sucks and a cool text model unfinished and usable and a text editor that cannot handle complicated stuff because it is not ready, etc. etc. > it feels bad. it tastes bad. and is not good at all. Yes, that does not feel good. But the fact that something is not completely finished is in the first place the responsibility of who started it in the first place - they did not drive there work all the way through (including integration, documentation, actively supporting it for a couple of years). > Esteban > >> >> 1. This is not a criticism; they are just in a different business (cathedral >> building) >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/ANN-Sparta-v1-1-tp4919394p4919647.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. |
|
|
In reply to this post by NorbertHartl
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.
|
|
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:
|
|
|
In reply to this post by NorbertHartl
On 10/21/2016 07:30 AM, Norbert Hartl
wrote:
Dale,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 |
| Free forum by Nabble | Edit this page |