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

Re: [Pharo-dev] [ANN] Phanide - Pharo Native IDE

by Ronie Salgado

> > Great work, Ronie, it looks very promising! Keep in mind that we already > have an IDE - Pharo, so it would be cool to make the components of your IDE > as much reusable as possible and I think that most of them should be in the > standard image in future. I agree on the reusability part. BTW, I forgot to mention that the Phanide syntax highlighters are also automatically registered with the GT Inspector, so if you do a 'test.cpp' asFileReference inspect , you will also have the syntax highlighting. Best regards, Ronie 2017-12-26 13:12 GMT-03:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Great work, Ronie, it looks very promising! Keep in mind that we already > have an IDE - Pharo, so it would be cool to make the components of your IDE > as much reusable as possible and I think that most of them should be in the > standard image in future. > > Cheers, > -- Pavel > > 2017-12-24 21:05 GMT+01:00 Ronie Salgado <roniesalg(a)gmail.com>: > >> Hi, >> >> I am going to announce a project that I started in November: >> >> Phanide, Pharo Native IDE( currently a File Browser, and a syntax >> highlighting framework): https://github.com/ronsaldo/phanide >> >> [image: ImÃ¡genes integradas 3] >> >> [image: ImÃ¡genes integradas 4] >> >> As for the UI, I am just copying some existing stuff like Atom (the text >> editor that I am currently using). >> >> Now I have a couple of questions to the mailing list: >> - In the fast table (used for the tree view): >> - How do I remove or add single elements without collapsing the whole >> tree? >> - In the Rubric text editor, how do I a put an icon (such as a breakpoint >> for GDB) in a specific line of the text, not in a index of the text? >> >> Merry Christmas, >> Ronie >> > >

Dec. 26, 2017

Re: [Pharo-dev] [ANN] Phanide - Pharo Native IDE

by Pavel Krivanek

Great work, Ronie, it looks very promising! Keep in mind that we already have an IDE - Pharo, so it would be cool to make the components of your IDE as much reusable as possible and I think that most of them should be in the standard image in future. Cheers, -- Pavel 2017-12-24 21:05 GMT+01:00 Ronie Salgado <roniesalg(a)gmail.com>: > Hi, > > I am going to announce a project that I started in November: > > Phanide, Pharo Native IDE( currently a File Browser, and a syntax > highlighting framework): https://github.com/ronsaldo/phanide > > [image: ImÃ¡genes integradas 3] > > [image: ImÃ¡genes integradas 4] > > As for the UI, I am just copying some existing stuff like Atom (the text > editor that I am currently using). > > Now I have a couple of questions to the mailing list: > - In the fast table (used for the tree view): > - How do I remove or add single elements without collapsing the whole > tree? > - In the Rubric text editor, how do I a put an icon (such as a breakpoint > for GDB) in a specific line of the text, not in a index of the text? > > Merry Christmas, > Ronie >

Dec. 26, 2017

Re: [Pharo-dev] Simple game framework

by Hilaire

Read. SDL + Cairo is the way you have been. I did not imagine Cairo was good at manipulating block of bitmap. Is Cairo stable over time in Pharo? I wonder will it be wiped out. More generally, I wonder what is the stable ground to build graphic application on Pharo? Le 25/12/2017 Ã 19:32, ClÃ©ment Bera a Ã©critÂ : > See those ReadMe: > > https://github.com/clementbera/wizard-battle-arena > > https://github.com/clementbera/SpiderInvasion > > Audio has always been a problem to me. I successfully run audio files > with the open AL binding, but I failed to do so cross-platform. > Already key-bindings coherent cross platform is difficult. > > Cheers -- Dr. Geo http://drgeo.eu

Dec. 26, 2017

Re: [Pharo-dev] Building an application with P7

by Hilaire

I meant more tests in DrGeo to expose its features, and to discover where newer Pharo breaks it. Hilaire Le 25/12/2017 Ã 23:59, Ben Coman a Ã©critÂ : > > really took me a long time to get drgeo right on P3 because these > oddities only show up at runtime, under specific scenario. There > are easy to fix, thought. Writing more tests should help too. > > > It would be great to have Issues opened with new tests attached for > these specific cases > that currently fail which we can work on make green. > They make the problem nicely explicit to work on. > -- Dr. Geo http://drgeo.eu

Dec. 26, 2017

Re: [Pharo-dev] Building an application with P7

by Ben Coman

On 26 December 2017 at 01:51, Hilaire <hilaire(a)drgeo.eu> wrote: > Let's discuss it in another thread. > > Until now, I moved slowly to update the drgeo build script to adjust to > Tonel file repository and P7; mostly done now. Will now look for help from > Pavel to build the drgeo image from a tiny core. > > About the other problems to get a user ready drgeo application based on > the forthcoming P7: > > - set up an application 64bits VMs architecture for Linux, OS X and > Windows (aka one-click image). I understand the later may be a problem as > there is not yet 64bits VMs. > > - get over the strange oddities appearing with P7, long and tedious but > mandatory; otherwise this sets back drgeo as an end user (student, > teacher) will immediately run away if drgeo is unpredictable. It really > took me a long time to get drgeo right on P3 because these oddities only > show up at runtime, under specific scenario. There are easy to fix, > thought. Writing more tests should help too. > It would be great to have Issues opened with new tests attached for these specific cases that currently fail which we can work on make green. They make the problem nicely explicit to work on. cheers -ben > > Hilaire > > > Le 25/12/2017 Ã 15:57, Stephane Ducasse a Ã©crit : > >> 5. fulfill the promise of tiny image, aka bootstrap and 4. >>> >> Did you see that pavel produced a smaller image than the first >> bootstrapped version >> >> All these wishes are under construction, so likely to happen \o/ >>> >>> >>> I have personal three wishes (beside good health of course), sharing it >>> in >>> case others are interested to hack on it too: >>> >>> A. get DrGeo working on P7, particularly on the bootstrap process. >>> >> Let us know the problem you face because this is important that you can. >> >> >> > -- > Dr. Geo > http://drgeo.eu > > > >

Dec. 25, 2017

Re: [Pharo-dev] How to restore image upgrade? was New Year Wishlist (2018) ?

by Ben Coman

As a half-way house, consider that "upgrade" scripts could be a good mechanism post-Release when changes should be less-deep/less-arduous on the system. This might avoid Esteban's time being needed to re-Release for each upgrade, with post-Release moving to a more community supported mechanism. This could scale better as we gain more users interested in long term support of their applications on a stable-release than the moving target of the development-edge. cheers -ben On 25 December 2017 at 23:11, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Nicolas > > We want to keep the live part of Pharo and incremental loading and it > is key for us. Now we should not be naive. > Most of the time we do not have the garantee that a change will work > when loaded. > > We proposed Pablo to work since two years on a really working dynamic > code loader and > Pablo has really nice results. But it takes time to evaluate if/how we > integrate its changes. > Pablo has an atomic coder loader and an incremental and modular class > builder. > He also designed a modular shutdown/startup list manager (in production). > > We want to be able to have a **real** and robust incremental load. > Right now as you know it and as in ANY smalltalk I can break the > system super easily. > There is no magic. I do not see how we can make sure that any piece of > code will be loaded > and do not break the system. > So our objective is to have a new infrastructure that we can updates > (like method hashes for example without having to > twists our mind and do five updates). > > Now about git, we want and we will have our lovely image as a working > directory but this requires engineering > because the image is another artefact that other languages do not have > to worry. > We will get there. > > Stef > > > On Sun, Dec 24, 2017 at 11:41 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > > > 2017-12-24 2:59 GMT+01:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > >> > >> My four wishes, in no particular order: > >> - Better code completion > >> - Git in Pharo as easy as using Git for other languages > > > > The recipe is easy: turn pharo into a file based edit-compile-run > language > > and expunge those live object burden ;) > > Let me explain why it's not just trolling. > > Currently we have to download an image made by a bot. > > Pharo has gradually lost the power to upgrade the image (it's not new). > > > > If we recognize that an image acts like a workspace, and want to let the > > pull/branch switch/etc work again... > > IOW going from one point to any other in source code graph > > and experience the full power of git like any other language, > > that means, in a live IDE, at least solving those two problems: > > - changing the tools that are used to upgrade the image (Compiler, > > MethodDictionary, Array, etc...) > > - correctly initialize all the states (including stange loops) > > If pharo has not managed to solve this with a linear one way history (the > > regularly broken update image option), > > how do you think this is going to be solved in the more general case? > > I call this the universal boostrap problem. > > > > IMO the logical next step is to separate the IDE > > (the Inanimate Desintegrated Environment of any other language). > > > > Maybe we don't have to bend Pharo too much to git if it does not fit. > > The goal: as easy might be not that easy. > > > > > >> - Bloc on Steroid > >> - Being able to interrupt any process and endless loop using > Cmd-. > >> > >> Merry Christmas to all of you! > >> Alexandre > >> > >> > >> > >> > On Dec 23, 2017, at 1:58 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > >> > wrote: > >> > > >> > Hi everybody, > >> > > >> > This looks like a good moment of the year to ask all of you what would > >> > you want to see in Pharo next year. > >> > Features, improvements, radical changes, etcâ¦. whatever you want. > >> > > >> > Of course, this list will not be a roadmap and it does not means we > will > >> > implement all of it (as always, time drives our possibilities), but > is a > >> > good moment for us a a community to check where we are and where we > wan to > >> > go next :) > >> > > >> > So, letâs those wishes come! > >> > > >> > cheers, > >> > Esteban > >> > >> > > > >

Dec. 25, 2017

Re: [Pharo-dev] New Year Wishlist (2018) ?

by Ben Coman

On 25 December 2017 at 22:58, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > On Mon, Dec 25, 2017 at 2:17 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > > A GUI builder is always a nice thing ... and there already was an attempt > > for Pharo: > > > > http://www.squeaksource.com/UIBuilder/ > > > > Now marked as "Failed attempt of develop a UI builder for > Pharo-Smalltalk. That version > > only works in Pharo 1.1. Is opened for any developer.". > > > > Dont know why it failed ... maybe because the UI (especially with > Morphic legacy) > > is still too shaky are in Pharo. > > The developer stopped when he saw that he could not build a excel like > grid. > Oh, then let me add an Excel-like grid as my Christmas wish (or does FastTable already provide much of this?) cheers -ben

Dec. 25, 2017

Re: [Pharo-dev] New Year Wishlist (2018) ?

by serge.stinckwich＠gmail.com

Yes we talk about something like that with ClÃ©ment some months ago. EnvoyÃ© de mon iPhone > Le 25 dÃ©c. 2017 Ã 20:29, Dimitris Chloupis <kilon.alios(a)gmail.com> a Ã©crit : > > >> On Mon, Dec 25, 2017 at 3:18 PM Torsten Bergmann <astares(a)gmx.de> wrote: >> A GUI builder is always a nice thing ... and there already was an attempt >> for Pharo: >> >> http://www.squeaksource.com/UIBuilder/ >> >> Now marked as "Failed attempt of develop a UI builder for Pharo-Smalltalk. That version >> only works in Pharo 1.1. Is opened for any developer.". >> >> Dont know why it failed ... maybe because the UI (especially with Morphic legacy) >> is still too shaky are in Pharo. >> >> But I guess the order will be/needs to be: >> >> - good and stable graphics framework (maybe solved with Bloc) >> - good and stable standardized widget set (maybe solved with Brick) >> - then place a UI builder on top of it >> >> Bye > > Yeap that's the ideology about GUI designers , which is why so few IDE's have them. It's like the man waiting for the perfect woman to marry, ending up all alone and miserable. > > As a designer myself I cannot follow easily this ideology. Actually I cannot follow it at all. > > I see it the exact opposite way, if you don't have a good GUI designer , your ability to provide a stable and powerful GUI API will be limited because less people will use it. > > The most stable and powerful GUI api I ever used was VCL , the standard library of Delphi and surprise, surprise it has a GUI designer. The most powerful I used so far. > > Open source wise QT dominates , surprise , surprise it has a very powerful GUI designer. > > On Windows you have VS studio GUI designer on MacOS and iOS the XCode GUI Designer and so forth. > > There a ton of GUI APIs out there that almost none uses, is it because they are not stable ? > > Well ... *cough* Windows *cough* ... sure. > > Making GUIs via code, is not as much fun, its slower and ends up being also less flexible as you can easily lose track of what you intend to do trying to understand the internals of a GUI API. Not fun at all. Especially if you experienced the horrors of MFC. > > But I am realistic , don't expect a GUI designer any time soon in Pharo. They are very hard to make and coders being allergic to GUIs does not help motivate to make one. > > I am ok with just a modular image format. > > Also I drink my own poison. I have made my own GUI API in Python with OpenGL (used from inside Blender for an application I am developing) very loosely inspired by some things I liked about Morphic. The more complex it becomes the more I feel the need to create a designer that will handle the boring stuff for me. > > For now I use the excellent excuse you provide of stability and inability to promise the structure of the GUI API in the future. But its an excuse with an expiration date. Making the GUI I have in my head using plain code , without a GUI designer, is a nightmare that is highly unlikely I will let myself experience. > > On the other hand when one makes his own GUI API the good news is that he can make it fits well in the workflow of a GUI designer. This way instead of trying to make the Designer according to the API , I make the API according to the designer. > > But the good news is that it has helped me realize the amount work needed to put in GUI API to become really useful. Fortunately making API to find only my needs has made things far easier and far smaller. I cannot imagine making something like Bloc and keeping my sanity. This way the next time I complain about a GUI API, I will have a whole different level of respect for the developers behind it.

Dec. 25, 2017

Re: [Pharo-dev] New Year Wishlist (2018) ?

by Dimitris Chloupis

On Mon, Dec 25, 2017 at 3:18 PM Torsten Bergmann <astares(a)gmx.de> wrote: > A GUI builder is always a nice thing ... and there already was an attempt > for Pharo: > > http://www.squeaksource.com/UIBuilder/ > > Now marked as "Failed attempt of develop a UI builder for Pharo-Smalltalk. > That version > only works in Pharo 1.1. Is opened for any developer.". > > Dont know why it failed ... maybe because the UI (especially with Morphic > legacy) > is still too shaky are in Pharo. > > But I guess the order will be/needs to be: > > - good and stable graphics framework (maybe solved with Bloc) > - good and stable standardized widget set (maybe solved with Brick) > - then place a UI builder on top of it > > Bye > Yeap that's the ideology about GUI designers , which is why so few IDE's have them. It's like the man waiting for the perfect woman to marry, ending up all alone and miserable. As a designer myself I cannot follow easily this ideology. Actually I cannot follow it at all. I see it the exact opposite way, if you don't have a good GUI designer , your ability to provide a stable and powerful GUI API will be limited because less people will use it. The most stable and powerful GUI api I ever used was VCL , the standard library of Delphi and surprise, surprise it has a GUI designer. The most powerful I used so far. Open source wise QT dominates , surprise , surprise it has a very powerful GUI designer. On Windows you have VS studio GUI designer on MacOS and iOS the XCode GUI Designer and so forth. There a ton of GUI APIs out there that almost none uses, is it because they are not stable ? Well ... *cough* Windows *cough* ... sure. Making GUIs via code, is not as much fun, its slower and ends up being also less flexible as you can easily lose track of what you intend to do trying to understand the internals of a GUI API. Not fun at all. Especially if you experienced the horrors of MFC. But I am realistic , don't expect a GUI designer any time soon in Pharo. They are very hard to make and coders being allergic to GUIs does not help motivate to make one. I am ok with just a modular image format. Also I drink my own poison. I have made my own GUI API in Python with OpenGL (used from inside Blender for an application I am developing) very loosely inspired by some things I liked about Morphic. The more complex it becomes the more I feel the need to create a designer that will handle the boring stuff for me. For now I use the excellent excuse you provide of stability and inability to promise the structure of the GUI API in the future. But its an excuse with an expiration date. Making the GUI I have in my head using plain code , without a GUI designer, is a nightmare that is highly unlikely I will let myself experience. On the other hand when one makes his own GUI API the good news is that he can make it fits well in the workflow of a GUI designer. This way instead of trying to make the Designer according to the API , I make the API according to the designer. But the good news is that it has helped me realize the amount work needed to put in GUI API to become really useful. Fortunately making API to find only my needs has made things far easier and far smaller. I cannot imagine making something like Bloc and keeping my sanity. This way the next time I complain about a GUI API, I will have a whole different level of respect for the developers behind it.

Dec. 25, 2017

Re: [Pharo-dev] Simple game framework

by ClÃ©ment Bera

See those ReadMe: https://github.com/clementbera/wizard-battle-arena https://github.com/clementbera/SpiderInvasion Audio has always been a problem to me. I successfully run audio files with the open AL binding, but I failed to do so cross-platform. Already key-bindings coherent cross platform is difficult. Cheers On Mon, Dec 25, 2017 at 6:58 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > You may have different kind of games; for example in 2D games, it could be > fixed frame, side scrolling, up scrolling, isometric, etc. To get it > started easily, it could come with graphic and audio banks. > > I really don't have much idea how such a general system should be > designed. Only wrote once a commercial decades ago on ARM code. > > Will look a the bloc tutorial for game[1] > > [1] https://github.com/pharo-graphics/Tutorials/ > > > Le 25/12/2017 Ã 15:57, Stephane Ducasse a Ã©crit : > >> B. Build an environment in Pharo to develop simple games, targeted for >>> kids. >>> There are some teenagers in my school likely to get interested on such >>> courses. If it could result in standalone games build thanks to wish 4., >>> so >>> good. >>> >> I'm interested into that this is why I proposed to "laura" >> maximilliano to work on such framework. >> Now I never got the time to do a pass over it and to release what I >> learned. >> - direction >> - handling on moves. >> - I created a grid data structure but this is the least interesting >> part. >> >> If you want we can discuss what I learned. >> Also students in Prague are building games on top of Bloc. >> >> >> > -- > Dr. Geo > http://drgeo.eu > > > > -- ClÃ©ment BÃ©ra Pharo consortium engineer https://clementbera.wordpress.com/ BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Dec. 25, 2017