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
On 12/23/2017 05:58 PM, Esteban Lorenzano wrote:
Hi everybody,
Hi :)
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.
I'll list the things I wanted the most those last months :) - To be able to load a private git project from a private server via Metacello API - To be able to depend on a git project from a private server in BaselineOf/ConfigurationOf - 64bits vm more recent that does not crash 1/4 of the time (It would help to deploy apps for some customers with older linux distributions) - 64bits Windows vm (But as far as I know, there is progress on this side already) - Continue to push Iceberg (I am not really specific because I want a lot on that part. For more details, I open issues on Iceberg repository often :) ) All those points are in the optic to make business with Pharo easier.
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 :)
Of course :)
So, letâs those wishes come!
Also, I would like to thanks everyone because I really like my Pharo journey and it would not be possible without you! :)
cheers, Esteban
-- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
- To be able to depend on a git project from a private server/
repo
in BaselineOf/ConfigurationOf
and automatically clone using SSH keys if needed
CyrilFerlicot wrote * * * * (Additions to above in bold)
STABILITY Of course!
I've been dreaming of most of the rest of my wishlist since 1.1, and it seems we've been creeping closer and closer: - Clean, stable low-level UI framework preserving the liveness and directness of Morphic, which also is infinitely zoomable and supports multiple (potentially simultaneously-running) worlds - 100% customizable (per instance) keybindings - Clean, customizable text editor with intuitive text model (sad to see Tx disappear, but we seem to have a replacement brewing) - Multi OS window support (not sure how close we are here) - Versionner (or its replacement) support for Baselines - hand editing is a draaaag Overall, I'm very thankful for all the progress we've made so far. Many of my wishlist items have been crossed off. Some bigger ones were: - Intuitive file library (FS) - Easy (low-barrier) contribution to other people's projects (via git/GH support) - Image management (Launcher) - Image auto-customization (startup scripts) - Single FFI library with must-have features from different existing (e.g. async callbacks) (almost there?) - Lots of integration with standard formats (NeoCSV/JSON, Pillar for MD) - Massive CI, including issue tracker integration - Cherry pick commits (Iceberg and Komitter before) - Real package model, with meta-data (RPackage and manifests) - In-editor critics with auto-transformations I can't wait to see what 2018 brings! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
On 12/23/2017 06:57 PM, Cyril Ferlicot D. wrote:
On 12/23/2017 05:58 PM, Esteban Lorenzano wrote:
Hi everybody,
Hi :)
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.
I'll list the things I wanted the most those last months :)
- To be able to load a private git project from a private server via Metacello API - To be able to depend on a git project from a private server in BaselineOf/ConfigurationOf - 64bits vm more recent that does not crash 1/4 of the time (It would help to deploy apps for some customers with older linux distributions) - 64bits Windows vm (But as far as I know, there is progress on this side already) - Continue to push Iceberg (I am not really specific because I want a lot on that part. For more details, I open issues on Iceberg repository often :) )
All those points are in the optic to make business with Pharo easier.
I also forgot: a real headless :)
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 :)
Of course :)
So, letâs those wishes come!
Also, I would like to thanks everyone because I really like my Pharo journey and it would not be possible without you! :)
cheers, Esteban
-- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
On Wed, Dec 27, 2017 at 04:41:56PM +0100, Cyril Ferlicot D. wrote:
I also forgot: a real headless :)
And real "embeddability". :-) I'll write GUIs with Pascal/Lazarus if I must. Being able to implement domain logic stuff in Pharo embedded into the application will super charge productivity. Pierce
On Dec 29, 2017 02:48, "Pierce Ng" <pierce@samadhiweb.com> wrote: On Wed, Dec 27, 2017 at 04:41:56PM +0100, Cyril Ferlicot D. wrote:
I also forgot: a real headless :)
And real "embeddability". :-) I'll write GUIs with Pascal/Lazarus if I must. That would actually suit me very well too. Being able to implement domain logic stuff in Pharo embedded into the application will super charge productivity. +1 million Phil Pierce
My four wishes, in no particular order: - Better code completion - Git in Pharo as easy as using Git for other languages - 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@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
Hi Esteban, Many things come to mind: vm side ======= - working SSL for all platforms supporting newest TLS - Pharo 64 bit VM for Windows - better and more VM plugins (like the camera plugin which would allow us more collaboration) - threaded vm for non-blocking usage - the VM in a DLL image - cleaning up - Calypso inclusion - Class annotations in the default image - Versionner for editing baselines (instead of manually editing dependencies) - unification of all the quality rules - support for other content types in browser (like highlighted XML, JSON, Js, ...) and managing non-smalltalk project code in git too at the level of projects - better completion - Bloc inclusion of blocs - better widgets and UI - a better catalog ("Index") - a better file browser - filing in/filing out Tonel files also in browser, change sorter, file list (similar to st files) - support for I18N (with tools, maybe binding to lib gettext) general - even more tech talks - more collaboration tools Also: - making a stable but updateable launcher the default install which is working on all platforms so one can use it for Pharo installation and sorting out version or platform specific install issues. If the list is too short then tell me ;) Bye T.
Gesendet: Samstag, 23. Dezember 2017 um 17:58 Uhr Von: "Esteban Lorenzano" <estebanlm@gmail.com> An: members-consortium@pharo.org, "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: [Pharo-dev] New Year Wishlist (2018) ?
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
Hi Esteban, - https://github.com/pharo-project/pharo-vm/pull/142 Thanks! Alistair On 23 December 2017 at 17:58, Esteban Lorenzano <estebanlm@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
Hi. Not blocking FFI, please 2017-12-23 17:58 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
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
For me 100% bootstrap and anything that helps me minimize the image or completely get rid of it. Second place is a GUI designer. Third place, world peace. Santa hates me :D On Sun, Dec 24, 2017 at 8:14 PM Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi.
Not blocking FFI, please
2017-12-23 17:58 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
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
Oh, you asked for that Esteban :) 1. stability 2. Tonel is a nice way to export file (its granularity is just right, bravo Esteban!) and commit to arbitrary repository, experimenting it with DrGeo, and it is nice to commit code[1] along other data files of the project (graphics, doc, translation, etc.). Got some an when non ascii characters were present in the source code, people reported it there. Likely to be fixed :) 3. vectorial interface, oh already on its way 4. application builder. Smalltalk/X has a GUI to build a standalone application, was not able to get it working, but it probably worked at some time in the past (see screenshot). Such a feature in Pharo will be fantastic, and likely a kill feature for the ones developing stand alone application; yes there are still some ;-) 5. fulfill the promise of tiny image, aka bootstrap and 4. 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. 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. C. Develop a white board application, easy to extend to add third party features. The OpenBoard[2] we are using in school are merely goods (can't get the right tooling to do geometry for example), handwriting is not nice, hacking on it is super complicated (C++ code), not to mention the building process. A Pharo based one will be fantastic and much easy to hack. Have a nice Christmas! [1] http://bazaar.launchpad.net/~drgeo-developers/drgeo/trunk/files/head:/src/ [2] http://openboard.ch Le 23/12/2017 à 17:58, Esteban Lorenzano a écrit :
So, letâs those wishes come!
-- Dr. Geo http://drgeo.eu
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 T.
Gesendet: Montag, 25. Dezember 2017 um 12:33 Uhr Von: Hilaire <hilaire@drgeo.eu> An: pharo-dev@lists.pharo.org Betreff: Re: [Pharo-dev] New Year Wishlist (2018) ?
Oh, you asked for that Esteban :)
1. stability
2. Tonel is a nice way to export file (its granularity is just right, bravo Esteban!) and commit to arbitrary repository, experimenting it with DrGeo, and it is nice to commit code[1] along other data files of the project (graphics, doc, translation, etc.). Got some an when non ascii characters were present in the source code, people reported it there. Likely to be fixed :)
3. vectorial interface, oh already on its way
4. application builder. Smalltalk/X has a GUI to build a standalone application, was not able to get it working, but it probably worked at some time in the past (see screenshot). Such a feature in Pharo will be fantastic, and likely a kill feature for the ones developing stand alone application; yes there are still some ;-)
5. fulfill the promise of tiny image, aka bootstrap and 4.
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.
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.
C. Develop a white board application, easy to extend to add third party features. The OpenBoard[2] we are using in school are merely goods (can't get the right tooling to do geometry for example), handwriting is not nice, hacking on it is super complicated (C++ code), not to mention the building process. A Pharo based one will be fantastic and much easy to hack.
Have a nice Christmas!
[1] http://bazaar.launchpad.net/~drgeo-developers/drgeo/trunk/files/head:/src/ [2] http://openboard.ch
Le 23/12/2017 à 17:58, Esteban Lorenzano a écrit :
So, letâs those wishes come!
-- Dr. Geo http://drgeo.eu
On Mon, Dec 25, 2017 at 2:17 PM, Torsten Bergmann <astares@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. I tried to rescue its effort but it was too large to recover.
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 T.
Gesendet: Montag, 25. Dezember 2017 um 12:33 Uhr Von: Hilaire <hilaire@drgeo.eu> An: pharo-dev@lists.pharo.org Betreff: Re: [Pharo-dev] New Year Wishlist (2018) ?
Oh, you asked for that Esteban :)
1. stability
2. Tonel is a nice way to export file (its granularity is just right, bravo Esteban!) and commit to arbitrary repository, experimenting it with DrGeo, and it is nice to commit code[1] along other data files of the project (graphics, doc, translation, etc.). Got some an when non ascii characters were present in the source code, people reported it there. Likely to be fixed :)
3. vectorial interface, oh already on its way
4. application builder. Smalltalk/X has a GUI to build a standalone application, was not able to get it working, but it probably worked at some time in the past (see screenshot). Such a feature in Pharo will be fantastic, and likely a kill feature for the ones developing stand alone application; yes there are still some ;-)
5. fulfill the promise of tiny image, aka bootstrap and 4.
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.
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.
C. Develop a white board application, easy to extend to add third party features. The OpenBoard[2] we are using in school are merely goods (can't get the right tooling to do geometry for example), handwriting is not nice, hacking on it is super complicated (C++ code), not to mention the building process. A Pharo based one will be fantastic and much easy to hack.
Have a nice Christmas!
[1] http://bazaar.launchpad.net/~drgeo-developers/drgeo/trunk/files/head:/src/ [2] http://openboard.ch
Le 23/12/2017 à 17:58, Esteban Lorenzano a écrit :
So, letâs those wishes come!
-- Dr. Geo http://drgeo.eu
About the application builder we will continue to work on the effort and lamrc is interested to show that we can build real applications with Pharo. So I really hope that something will happen this year. Stef On Mon, Dec 25, 2017 at 3:58 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
On Mon, Dec 25, 2017 at 2:17 PM, Torsten Bergmann <astares@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. I tried to rescue its effort but it was too large to recover.
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 T.
Gesendet: Montag, 25. Dezember 2017 um 12:33 Uhr Von: Hilaire <hilaire@drgeo.eu> An: pharo-dev@lists.pharo.org Betreff: Re: [Pharo-dev] New Year Wishlist (2018) ?
Oh, you asked for that Esteban :)
1. stability
2. Tonel is a nice way to export file (its granularity is just right, bravo Esteban!) and commit to arbitrary repository, experimenting it with DrGeo, and it is nice to commit code[1] along other data files of the project (graphics, doc, translation, etc.). Got some an when non ascii characters were present in the source code, people reported it there. Likely to be fixed :)
3. vectorial interface, oh already on its way
4. application builder. Smalltalk/X has a GUI to build a standalone application, was not able to get it working, but it probably worked at some time in the past (see screenshot). Such a feature in Pharo will be fantastic, and likely a kill feature for the ones developing stand alone application; yes there are still some ;-)
5. fulfill the promise of tiny image, aka bootstrap and 4.
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.
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.
C. Develop a white board application, easy to extend to add third party features. The OpenBoard[2] we are using in school are merely goods (can't get the right tooling to do geometry for example), handwriting is not nice, hacking on it is super complicated (C++ code), not to mention the building process. A Pharo based one will be fantastic and much easy to hack.
Have a nice Christmas!
[1] http://bazaar.launchpad.net/~drgeo-developers/drgeo/trunk/files/head:/src/ [2] http://openboard.ch
Le 23/12/2017 à 17:58, Esteban Lorenzano a écrit :
So, letâs those wishes come!
-- Dr. Geo http://drgeo.eu
On 25 December 2017 at 22:58, Stephane Ducasse <stepharo.self@gmail.com> wrote:
On Mon, Dec 25, 2017 at 2:17 PM, Torsten Bergmann <astares@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
In case of, at wish 4. I did not write a GUI builder but really an application builder: a tool to let you build up the image and the needed VMs, and pack it appropriately for the end user. As it is manually done for Dr.Geo. Le 25/12/2017 à 14:17, Torsten Bergmann a écrit :
A GUI builder is always a nice thing ... and there already was an attempt for Pharo:
-- Dr. Geo http://drgeo.eu
On Mon, Dec 25, 2017 at 3:18 PM Torsten Bergmann <astares@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.
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@gmail.com> a écrit :
On Mon, Dec 25, 2017 at 3:18 PM Torsten Bergmann <astares@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.
Hi hilaire what is nice is that we have most of the same wishes ;) On Mon, Dec 25, 2017 at 12:33 PM, Hilaire <hilaire@drgeo.eu> wrote:
Oh, you asked for that Esteban :)
1. stability
2. Tonel is a nice way to export file (its granularity is just right, bravo Esteban!) and commit to arbitrary repository, experimenting it with DrGeo, and it is nice to commit code[1] along other data files of the project (graphics, doc, translation, etc.). Got some an when non ascii characters were present in the source code, people reported it there. Likely to be fixed :)
3. vectorial interface, oh already on its way
4. application builder. Smalltalk/X has a GUI to build a standalone application, was not able to get it working, but it probably worked at some time in the past (see screenshot). Such a feature in Pharo will be fantastic, and likely a kill feature for the ones developing stand alone application; yes there are still some ;-)
5. fulfill the promise of tiny image, aka bootstrap and 4.
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.
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.
C. Develop a white board application, easy to extend to add third party features. The OpenBoard[2] we are using in school are merely goods (can't get the right tooling to do geometry for example), handwriting is not nice, hacking on it is super complicated (C++ code), not to mention the building process. A Pharo based one will be fantastic and much easy to hack.
Have a nice Christmas!
[1] http://bazaar.launchpad.net/~drgeo-developers/drgeo/trunk/files/head:/src/ [2] http://openboard.ch
Le 23/12/2017 à 17:58, Esteban Lorenzano a écrit :
So, letâs those wishes come!
-- Dr. Geo http://drgeo.eu
1. stability
2. Tonel is a nice way to export file (its granularity is just right, bravo Esteban!) and commit to arbitrary repository, experimenting it with DrGeo, and it is nice to commit code[1] along other data files of the project (graphics, doc, translation, etc.). Got some an when non ascii characters were present in the source code, people reported it there. Likely to be fixed :)
3. vectorial interface, oh already on its way
4. application builder. Smalltalk/X has a GUI to build a standalone application, was not able to get it working, but it probably worked at some time in the past (see screenshot). Such a feature in Pharo will be fantastic, and likely a kill feature for the ones developing stand alone application; yes there are still some ;-)
We would like the same. Now spec was an increment in that direction because behind the UI builder you need to reuse the model. So with a pass on spec we will be set to be able to build the builder part
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.
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.
C. Develop a white board application, easy to extend to add third party features. The OpenBoard[2] we are using in school are merely goods (can't get the right tooling to do geometry for example), handwriting is not nice, hacking on it is super complicated (C++ code), not to mention the building process. A Pharo based one will be fantastic and much easy to hack.
Is Pharo running on this?
Have a nice Christmas!
[1] http://bazaar.launchpad.net/~drgeo-developers/drgeo/trunk/files/head:/src/ [2] http://openboard.ch
Le 23/12/2017 à 17:58, Esteban Lorenzano a écrit :
So, letâs those wishes come!
-- Dr. Geo http://drgeo.eu
I really don't mean a GUI builder :-) Le 25/12/2017 à 15:57, Stephane Ducasse a écrit :
4. application builder. Smalltalk/X has a GUI to build a standalone application, was not able to get it working, but it probably worked at some time in the past (see screenshot). Such a feature in Pharo will be fantastic, and likely a kill feature for the ones developing stand alone application; yes there are still some;-) We would like the same. Now spec was an increment in that direction because behind the UI builder you need to reuse the model. So with a pass on spec we will be set to be able to build the builder part
-- Dr. Geo http://drgeo.eu
Yes saw and my second answer took that into account. We were discussing about making sure that we can write applications vs. code. We should be able to package an application. The experience accumulated with the launcher and the effort on making Pharo silent (not forcing to write everywhere files) are in that direction too. Stef On Mon, Dec 25, 2017 at 6:25 PM, Hilaire <hilaire@drgeo.eu> wrote:
I really don't mean a GUI builder :-)
Le 25/12/2017 à 15:57, Stephane Ducasse a écrit :
4. application builder. Smalltalk/X has a GUI to build a standalone application, was not able to get it working, but it probably worked at some time in the past (see screenshot). Such a feature in Pharo will be fantastic, and likely a kill feature for the ones developing stand alone application; yes there are still some;-)
We would like the same. Now spec was an increment in that direction because behind the UI builder you need to reuse the model. So with a pass on spec we will be set to be able to build the builder part
-- Dr. Geo http://drgeo.eu
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. 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
On 26 December 2017 at 01:51, Hilaire <hilaire@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
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
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
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@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
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
Hi Hilaire yes you can have multiple approaches. I was focusing on tiles-based ones: sokoban, miners.. SDL2.0 is our plan. For Cairo we asked Bloc guys to make sure that we can use Cairo as back end to avoid to have 20 mb by default with Mozz2d (and mozz2d is not really packaged by their creators so high risk) so Cairo should stay around. Now I would like to use Bloc for tile based games. Stef On Tue, Dec 26, 2017 at 4:19 PM, Hilaire <hilaire@drgeo.eu> wrote:
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
What is the reason using Cairo over SDSL? Is not SDL just enought? Hilaire Le 25/12/2017 à 19:32, Clément Bera a écrit :
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.
-- Dr. Geo http://drgeo.eu
On Thu, Dec 28, 2017 at 4:39 PM, Hilaire <hilaire@drgeo.eu> wrote:
What is the reason using Cairo over SDSL? Is not SDL just enought?
My understanding is that SDL provides the surface to draw on as part of the window, but not a 2D vector graphic engine on top. You've got only draw Line/Rect/pixel functions in SDL. To render a svg/png/jpeg that you want for games on the SDL surface, the normal way is to use a third party library such as Cairo. For 3D I believe people use SDL combined with open GL or direct3D instead of Cairo but I don't know the details. For events (keyboard, mouse, joypad) I use SDL event management and it works differently on each OS. I wrote in the readMe the different set-ups to make it work on each OS. On Windows and Linux I can use the latest Pharo. On Mac I use old Pharo 5 images. I guess it's possible to use SDL for audio, but it seems there is no code relative to audio in the SDL binding and in OSWindow in Pharo. That's why I did not go that way. I tried multiple things but I successfully run audio code in Pharo only with the openAL binding and .wav file (and even in this case, I had to install external librairies in Mac OS...). Whichever if Cairo stays around or not does not really matter, normally one uses Cairo through Athens or Sparta, abstraction layers on top of 2D graphic engines. I've worked with other 2D engines and the API are always almost the same, so I have no doubt that if Cairo support is dropped we can re-bind Athens/Sparta with another 2D engine (such as engines used by web browsers).
Hilaire
Le 25/12/2017 à 19:32, Clément Bera a écrit :
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.
-- 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
Problem is that people , coders and users, tend to underestimate the complexity of game development. 99% of the technology we use nowadays is game based. Powerful GPUs utilized by consumer computers and supercomputer alike to deal with highly complex problems like cancer research and simulations of the Bing Bang. Massive memory that is millions time large than technology that existed 30 years ago. A computer with 128GB of memory is exactly 1 million times bigger than my first computer with 128 kbs of memory that will become 30 years old in exactly one year. Massive super fast hard drives. Multi core CPUs The internet. Anything you look around you has so massively progressed , only because of high end games that have created the most profitable business for half a century. No other kind of software comes remotely close to pushing the hardware to such extremes and yet being so massively popular as high end games. So game APIs are extremely complex even for the simplest games. In Python for example we have , or rather had , Pygame , itâs as massively popular with beginners game developers as its massively unpopular with profession or very experienced amateur game developers. The latest Pygame is basically SDL with some extra game stuff. Why people donât use it beyond proof of concept ? One word âSimpleâ What the rest of the computer world pursue as the holy grail in game development is nothing more than a bad allergy . Why ? Because You will be far better in embracing the extremely complex engines on the market even for the creation of the simplest games. The moment you decide that using such an engine is an overkill for your so simple needs and that you donât have to endure their very steep learning curve is the moment you condemn yourself to a full rewrite if there is a remote chance of taking the game one step further. We all know how much fun full rewrites are. In short making games is no game. Go use a professional engine and you can thank me later. On Thu, 28 Dec 2017 at 19:53, Clément Bera <bera.clement@gmail.com> wrote:
On Thu, Dec 28, 2017 at 4:39 PM, Hilaire <hilaire@drgeo.eu> wrote:
What is the reason using Cairo over SDSL? Is not SDL just enought?
My understanding is that SDL provides the surface to draw on as part of the window, but not a 2D vector graphic engine on top. You've got only draw Line/Rect/pixel functions in SDL. To render a svg/png/jpeg that you want for games on the SDL surface, the normal way is to use a third party library such as Cairo.
For 3D I believe people use SDL combined with open GL or direct3D instead of Cairo but I don't know the details.
For events (keyboard, mouse, joypad) I use SDL event management and it works differently on each OS. I wrote in the readMe the different set-ups to make it work on each OS. On Windows and Linux I can use the latest Pharo. On Mac I use old Pharo 5 images.
I guess it's possible to use SDL for audio, but it seems there is no code relative to audio in the SDL binding and in OSWindow in Pharo. That's why I did not go that way. I tried multiple things but I successfully run audio code in Pharo only with the openAL binding and .wav file (and even in this case, I had to install external librairies in Mac OS...).
Whichever if Cairo stays around or not does not really matter, normally one uses Cairo through Athens or Sparta, abstraction layers on top of 2D graphic engines. I've worked with other 2D engines and the API are always almost the same, so I have no doubt that if Cairo support is dropped we can re-bind Athens/Sparta with another 2D engine (such as engines used by web browsers).
Hilaire
Le 25/12/2017 à 19:32, Clément Bera a écrit :
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.
-- Dr. Geo http://drgeo.eu
-- Clément Béra Pharo consortium engineer https://clementbera.wordpress.com/ Bâtiment B 40, avenue Halley 59650 <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>Villeneuve d <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g> 'Ascq <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>
I found the mix of OSWindow+SDL+Athens very complex (tens of classes with hundreds of methods) and to produce code hard to understand (I look at your spider code). I will prefer fewer functionnality I can understand. For example, how can you copy a sprite on a SDL surface? Can you do it without Athens surface? Le 28/12/2017 à 18:51, Clément Bera a écrit :
Whichever if Cairo stays around or not does not really matter, normally one uses Cairo through Athens or Sparta, abstraction layers on top of 2D graphic engines. I've worked with other 2D engines and the API are always almost the same, so I have no doubt that if Cairo support is dropped we can re-bind Athens/Sparta with another 2D engine (such as engines used by web browsers).
-- Dr. Geo http://drgeo.eu
Hilaire why do you need to have a sprite on a SDL surface and why plain Athens is not good enough. Athens is an API not an implementation. It is like sparta: an API and you do not care about the library below. OSWindow is a layer on top of SDL and it is better than SDL directly to my understanding. So you should get Athens and SDL for event. What kind of game are you targeting? Did you look at Bloc? Because to me this is the way to go except if you want just a canvas and reimplement your event loop. in that case SDL + Athens should work. Stef On Sat, Dec 30, 2017 at 9:33 PM, Hilaire <hilaire@drgeo.eu> wrote:
I found the mix of OSWindow+SDL+Athens very complex (tens of classes with hundreds of methods) and to produce code hard to understand (I look at your spider code).
I will prefer fewer functionnality I can understand.
For example, how can you copy a sprite on a SDL surface? Can you do it without Athens surface?
Le 28/12/2017 à 18:51, Clément Bera a écrit :
Whichever if Cairo stays around or not does not really matter, normally one uses Cairo through Athens or Sparta, abstraction layers on top of 2D graphic engines. I've worked with other 2D engines and the API are always almost the same, so I have no doubt that if Cairo support is dropped we can re-bind Athens/Sparta with another 2D engine (such as engines used by web browsers).
-- Dr. Geo http://drgeo.eu
because simple things should be simple... Le 30/12/2017 à 22:32, Stephane Ducasse a écrit :
Hilaire
why do you need to have a sprite on a SDL surface and why plain Athens is not good enough. Athens is an API not an implementation. It is like sparta: an API and you do not care about the library below.
OSWindow is a layer on top of SDL and it is better than SDL directly to my understanding. So you should get Athens and SDL for event.
What kind of game are you targeting? Did you look at Bloc? Because to me this is the way to go except if you want just a canvas and reimplement your event loop. in that case SDL + Athens should work.
Stef
On Sat, Dec 30, 2017 at 9:33 PM, Hilaire<hilaire@drgeo.eu> wrote:
I found the mix of OSWindow+SDL+Athens very complex (tens of classes with hundreds of methods) and to produce code hard to understand (I look at your spider code).
I will prefer fewer functionnality I can understand.
For example, how can you copy a sprite on a SDL surface? Can you do it without Athens surface?
Le 28/12/2017 à 18:51, Clément Bera a écrit :
Whichever if Cairo stays around or not does not really matter, normally one uses Cairo through Athens or Sparta, abstraction layers on top of 2D graphic engines. I've worked with other 2D engines and the API are always almost the same, so I have no doubt that if Cairo support is dropped we can re-bind Athens/Sparta with another 2D engine (such as engines used by web browsers). -- Dr. Geo http://drgeo.eu
-- Dr. Geo http://drgeo.eu
I am *exploring* if Pharo will be suitable to have a simple programming environment to let kids write simple 2D games, SDL was designed for that. Some of my students asked me about programming games, Smalltalk way of writing code will be neat, but the environment need to be accessible and not over engineered. Le 30/12/2017 à 22:32, Stephane Ducasse a écrit :
What kind of game are you targeting? Did you look at Bloc? Because to me this is the way to go except if you want just a canvas and reimplement your event loop. in that case SDL + Athens should work.
-- Dr. Geo http://drgeo.eu
Hi hilaire Some students at Prague are working on different 2D games with Bloc and this is working. Some did a sokoban, other a miner (check on pharo weekly). They use Bloc and I will ask them to make public their code. No need for SDL. SDL is ***low level***. Now modeling the board and proposing some abstractions that can be easily extended is difficult. and this is what lauraMaximilliano did in MetaBorg. It was on my todo to do a pass. I implemented a grid to help the design of board game. Now having direction/location can be good. What is interesting in the design of metaborg is that we do not test if an object can move to a place. We go to the place and the place pull the item. A wall will not pull for example while a empty slot will pull the item to move. I found it intriguing and I would like to know if this is working for more complex situation. Maximiliano implemented sokoban, tetris, snake, pacman with the same framwork. Now it is a bit abstract but an interesting experience. Stef On Sun, Dec 31, 2017 at 2:41 PM, Hilaire <hilaire@drgeo.eu> wrote:
I am *exploring* if Pharo will be suitable to have a simple programming environment to let kids write simple 2D games, SDL was designed for that.
Some of my students asked me about programming games, Smalltalk way of writing code will be neat, but the environment need to be accessible and not over engineered.
Le 30/12/2017 à 22:32, Stephane Ducasse a écrit :
What kind of game are you targeting? Did you look at Bloc? Because to me this is the way to go except if you want just a canvas and reimplement your event loop. in that case SDL + Athens should work.
-- Dr. Geo http://drgeo.eu
Hi Stef, A complete port of the SDL capabilities (http://wiki.libsdl.org/Introduction) will be super nice (audio) and improved stability. For your students, the perspective on the game is likely 2 months, may be 6 months; you know I have longer perspective - DrGeo was slowly developed and crafted for 20 years; therefore stability on the code is very important for me as I will have to work over long period. That's the reason I don't fell at ease relying on many code layers. For your students, as the horizon is counted in months it is a null consideration, not for me. Not to mention there are uncertainty over this layers. Moreover these layers will make hard to my student to understand what's going on, if they want to dig in. I am not sure how far will get me this reflexion, but for my students, I can imagine different models of 2D games: board games, horizontal/vertical scrolling games, isometric games. Each one can be optimized differently. Banks of sprites and audio will be already there to get started the students. The models will encapsulate SDL, as PyGame is doing, but still easilly accessible. I imagine such an environment to rely only on two layers: SDL and spec, the later if some dedicated user interface is needed for the game designer; but a lot should happen in the class browser. I found this Python PyGame code bellow rather easy to understand. Will it be possible to produce an equally understandable Smalltalk code with the layers your are proposing? importsys,pygamepygame.init()size=width,height=320,240speed=[2,2]black=0,0,0screen=pygame.display.set_mode(size)ball=pygame.image.load("ball.bmp")ballrect=ball.get_rect()while1:foreventinpygame.event.get():ifevent.type==pygame.QUIT:sys.exit()ballrect=ballrect.move(speed)ifballrect.left<0orballrect.right>width:speed[0]=-speed[0]ifballrect.top<0orballrect.bottom>height:speed[1]=-speed[1]screen.fill(black)screen.blit(ball,ballrect)pygame.display.flip() Hilaire Your time stamp bellow is a strike! ;)   vvvvvvvvvvvvvvvvvvvvvv Le 01/01/2018 à 00:00, Stephane Ducasse a écrit :
Hi hilaire
Some students at Prague are working on different 2D games with Bloc and this is working. Some did a sokoban, other a miner (check on pharo weekly).
They use Bloc and I will ask them to make public their code. No need for SDL. SDL is ***low level***.
Now modeling the board and proposing some abstractions that can be easily extended is difficult. and this is what lauraMaximilliano did in MetaBorg.
It was on my todo to do a pass. I implemented a grid to help the design of board game. Now having direction/location can be good.
What is interesting in the design of metaborg is that we do not test if an object can move to a place. We go to the place and the place pull the item. A wall will not pull for example while a empty slot will pull the item to move.
I found it intriguing and I would like to know if this is working for more complex situation.
Maximiliano implemented sokoban, tetris, snake, pacman with the same framwork. Now it is a bit abstract but an interesting experience.
Stef
On Sun, Dec 31, 2017 at 2:41 PM, Hilaire<hilaire@drgeo.eu> wrote:
I am*exploring* if Pharo will be suitable to have a simple programming environment to let kids write simple 2D games, SDL was designed for that.
Some of my students asked me about programming games, Smalltalk way of writing code will be neat, but the environment need to be accessible and not over engineered.
Le 30/12/2017 à 22:32, Stephane Ducasse a écrit :
What kind of game are you targeting? Did you look at Bloc? Because to me this is the way to go except if you want just a canvas and reimplement your event loop. in that case SDL + Athens should work. -- Dr. Geo http://drgeo.eu
-- Dr. Geo http://drgeo.eu
This code can be just in a method of subclass of BlGameElement. You should really try because Bloc is really nice. And this is not a layer this is the future Morphic. Now if you work on SDL instead of Athens (remember Athens is an API) when we will change SDL for the next low level framework you will have to change. Stef On Mon, Jan 1, 2018 at 5:50 PM, Hilaire <hilaire@drgeo.eu> wrote:
Hi Stef,
A complete port of the SDL capabilities (http://wiki.libsdl.org/Introduction) will be super nice (audio) and improved stability.
For your students, the perspective on the game is likely 2 months, may be 6 months; you know I have longer perspective - DrGeo was slowly developed and crafted for 20 years; therefore stability on the code is very important for me as I will have to work over long period. That's the reason I don't fell at ease relying on many code layers. For your students, as the horizon is counted in months it is a null consideration, not for me. Not to mention there are uncertainty over this layers. Moreover these layers will make hard to my student to understand what's going on, if they want to dig in.
I am not sure how far will get me this reflexion, but for my students, I can imagine different models of 2D games: board games, horizontal/vertical scrolling games, isometric games. Each one can be optimized differently. Banks of sprites and audio will be already there to get started the students. The models will encapsulate SDL, as PyGame is doing, but still easilly accessible.
I imagine such an environment to rely only on two layers: SDL and spec, the later if some dedicated user interface is needed for the game designer; but a lot should happen in the class browser.
I found this Python PyGame code bellow rather easy to understand. Will it be possible to produce an equally understandable Smalltalk code with the layers your are proposing?
importsys,pygamepygame.init()size=width,height=320,240speed=[2,2]black=0,0,0screen=pygame.display.set_mode(size)ball=pygame.image.load("ball.bmp")ballrect=ball.get_rect()while1:foreventinpygame.event.get():ifevent.type==pygame.QUIT:sys.exit()ballrect=ballrect.move(speed)ifballrect.left<0orballrect.right>width:speed[0]=-speed[0]ifballrect.top<0orballrect.bottom>height:speed[1]=-speed[1]screen.fill(black)screen.blit(ball,ballrect)pygame.display.flip()
Hilaire
Your time stamp bellow is a strike! ;) vvvvvvvvvvvvvvvvvvvvvv
Le 01/01/2018 à 00:00, Stephane Ducasse a écrit :
Hi hilaire
Some students at Prague are working on different 2D games with Bloc and this is working. Some did a sokoban, other a miner (check on pharo weekly).
They use Bloc and I will ask them to make public their code. No need for SDL. SDL is ***low level***.
Now modeling the board and proposing some abstractions that can be easily extended is difficult. and this is what lauraMaximilliano did in MetaBorg.
It was on my todo to do a pass. I implemented a grid to help the design of board game. Now having direction/location can be good.
What is interesting in the design of metaborg is that we do not test if an object can move to a place. We go to the place and the place pull the item. A wall will not pull for example while a empty slot will pull the item to move.
I found it intriguing and I would like to know if this is working for more complex situation.
Maximiliano implemented sokoban, tetris, snake, pacman with the same framwork. Now it is a bit abstract but an interesting experience.
Stef
On Sun, Dec 31, 2017 at 2:41 PM, Hilaire<hilaire@drgeo.eu> wrote:
I am*exploring* if Pharo will be suitable to have a simple programming environment to let kids write simple 2D games, SDL was designed for that.
Some of my students asked me about programming games, Smalltalk way of writing code will be neat, but the environment need to be accessible and not over engineered.
Le 30/12/2017 à 22:32, Stephane Ducasse a écrit :
What kind of game are you targeting? Did you look at Bloc? Because to me this is the way to go except if you want just a canvas and reimplement your event loop. in that case SDL + Athens should work.
-- Dr. Geo http://drgeo.eu
-- Dr. Geo http://drgeo.eu
IF there is a Pharo binding for SDL, why not audio from SDSL? Le 25/12/2017 à 19:32, Clément Bera a écrit :
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.
-- Dr. Geo http://drgeo.eu
I don't understand your question Le 25/12/2017 à 15:57, Stephane Ducasse a écrit :
C. Develop a white board application, easy to extend to add third party features. The OpenBoard[2] we are using in school are merely goods (can't get the right tooling to do geometry for example), handwriting is not nice, hacking on it is super complicated (C++ code), not to mention the building process. A Pharo based one will be fantastic and much easy to hack. Is Pharo running on this?
-- Dr. Geo http://drgeo.eu
Given the recent stirrings of AI-related applications in Pharo, I guess I'm wishing for vm support for vector operations/fast math. I heard something about that a while ago on the polymath chanel, so I figure it can't hurt to wish. Evan -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Hi Evan yes thierry was discussing with clement and we will see :). Stef On Mon, Dec 25, 2017 at 6:55 PM, Evan Donahue <emdonahu@gmail.com> wrote:
Given the recent stirrings of AI-related applications in Pharo, I guess I'm wishing for vm support for vector operations/fast math. I heard something about that a while ago on the polymath chanel, so I figure it can't hurt to wish.
Evan
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Hi Esteban, Thanks for asking. My one and only wish is more stability for the stable version, i.e. bug fixes for Pharo 6, especially the VMs but also the image. Thanks for Pharo! Cheers, Bernhard
Am 23.12.2017 um 17:58 schrieb Esteban Lorenzano <estebanlm@gmail.com>:
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
Tx Stephan I have too many dreams :) so I will have to prioritize but let's the first three :). Stef On Sun, Dec 31, 2017 at 12:58 PM, Stephan Eggermont <stephan@stack.nl> wrote:
Esteban Lorenzano <estebanlm@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.
I wish you all the time and good health to realize some of your Pharo dreams
Stephan
- stability - bloc - some sort of pretty cool and fast concurrent transactional object persistence :)
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
On 24 December 2017 at 00:58, Esteban Lorenzano <estebanlm@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!
Small enhancement that arises as I'm trying to design a Morph, Initially forgetting which corner of the screen is 0@0, raises the idea that in the GTInspector Morph tab, showing the coordinates of the mouse as it tracks over the morph would be useful. Maybe this would be less useful for Morphic using absolute co-ordinates, but good for Bloc using relative co-ordinates (IIUC). cheers -ben
On 24 December 2017 at 00:58, Esteban Lorenzano <estebanlm@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
IIUC, our continuous integration system really only checks that "new" error are not introduced. This seems of limited facility to encourage dealing with existing errors. So my wish is for... 1. TestRunner GUI results to be kept fault free. 2. Periodically scheduled human-driven reality check of [1.] cheers -ben
participants (19)
-
Alexandre Bergel -
Alistair Grant -
Ben Coman -
Bernhard Pieber -
Clément Bera -
Cyril Ferlicot D. -
Denis Kudriashov -
Dimitris Chloupis -
Esteban Lorenzano -
Evan Donahue -
Hilaire -
Petr Fischer -
philippe.back＠highoctane.be -
Pierce Ng -
Sean P. DeNigris -
serge.stinckwich＠gmail.com -
Stephan Eggermont -
Stephane Ducasse -
Torsten Bergmann