- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Yosemite & Pharo

by Sven Van Caekenberghe

On 15 Sep 2014, at 09:36, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi pharoers, > > so Iâve installed Yosemite beta and: > > 1) there were no problems with Pharo by now Good. > 2) sometimes Yosemite lags in general (on rich 3D graphics for e.g.) and battery life is worse. Hmm, let's hope they fix that ;-) > 3) the most important thing that Iâve noticed: there are no black bars if full screen mode. Is an improvement in Pharo, or just how Yosemite works? That would be excellent news, I missed that. That would then fix https://pharo.fogbugz.com/f/cases/12648/Full-screen-on-Mac-OS-X-10-9-partia… > Cheers. > Uko Thanks for testing and for the report.

Sept. 15, 2014

Yosemite & Pharo

by Yuriy Tymchuk

Hi pharoers, so Iâve installed Yosemite beta and: 1) there were no problems with Pharo by now 2) sometimes Yosemite lags in general (on rich 3D graphics for e.g.) and battery life is worse. 3) the most important thing that Iâve noticed: there are no black bars if full screen mode. Is an improvement in Pharo, or just how Yosemite works? Cheers. Uko

Sept. 15, 2014

Re: [Pharo-dev] About renaming API methods

by Damien Cassou

On Mon, Sep 15, 2014 at 9:16 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 1) add the same API to the current stable version this one would be great because I had problems with the FileSystem API between Pharo 2 and Pharo 3: in Pharo 3 I had deprecated warnings that I could not fix because Pharo 2 did not have the new API. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Sept. 15, 2014

About renaming API methods

by Marcus Denker

Hi, In case we rename methods that are used as part of the public API, I propose to do 1) add the same API to the current stable version (today this would be Pharo3 2) add a rule (in a âPort Pharo3 to Pharo4â category that finds the needed senders (if possible even with a transformation) Then depending on the use and importance -> deprecate the old API right away or -> just tag it as âto be deprecatedâ one version later or -> keep the old as âcompatibilityâ This should make it possible to clean up API (e.g. when there are typos in the selectorâ¦), while not disturbing users to much. *And* it will be possible to have affected code running both in Stable and Development. (This should not be a strict rule, more a âbest effortâ one, and there will always be cases where we can not do this or where it is not needed). Marcus

Sept. 15, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] c8ff39: 40225

by Marcus Denker

> 13833 rename String>>#withFirstCharacterDownshifted to > String>>#uncapitalized > https://pharo.fogbugz.com/f/cases/13833 > > I added two more issue to make that transition easier... (for the critic, we should have a "Pharo3 to Pharo4 porting" section) 14019 add critics rule for #withCaracterDownShifted -> #uncapitalized https://pharo.fogbugz.com/f/cases/14019/add-critics-rule-for-withCaracterDo… 14018 backport #uncapitalized to Pharo3 https://pharo.fogbugz.com/f/cases/14018/backport-uncapitalized-to-Pharo3

Sept. 15, 2014

Re: [Pharo-dev] AppeX

by phil＠highoctane.be

Thanks for that, I'll look into it. Rubric looks definitely nicer that the old thing. It opens a lot of doors and may allow me to do the little I wanted to do when I started using Pharo. Hey, patience pays off :-) Glamour indeed is a powerful tool to craft content explorers. Phil On Mon, Sep 15, 2014 at 6:44 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > As you could see in the Pillar highlighting support, Rubric can now handle > any syntax highlighting in a rather straightforward way. You can also > easily embed this in a Glamour browser. > > You can see the example in the GT-InspectorExtensions-Pillar. You can load > the code in a Moose image like this: > Gofer new > smalltalkhubUser: 'Pier' project: 'Pillar'; > configuration; > loadStable. > Gofer new > smalltalkhubUser: 'JanKurs' project: 'PetitParser'; > configurationOf: #PetitParserIslands; > load. > #ConfigurationOfPetitParserIslands asClass loadDevelopment. > Gofer new > smalltalkhubUser: 'Moose' project: 'GToolkit'; > package: 'GT-InspectorExtensions-Pillar'; > load. > > Cheers, > Doru > > > > On Fri, Sep 5, 2014 at 4:28 PM, Thierry Goubier <thierry.goubier(a)gmail.com > > wrote: > >> >> >> >> 2014-09-05 16:03 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >> >>> Maybe we can start small. >>> >>> I've current needs that could well be handled in the environment. >>> >>> The FileBrowser is in my view quite not used enough. >>> >>> When doing web applications, I deal with Javascript, CSS, content files >>> etc all the time. >>> >>> The FileBrowser allows to edit files in its content pane. >>> Doing an Accept (Alt-S) on the pane saves the file. >>> >>> So, instead of starting an external edit session in Vim, I mostly work >>> there for some smaller changes (like tweaking CSS). >>> >>> Now, if we could have a syntax highlighter in there it would be nice. >>> >> >> Yes. Anybody knows what is the API for adding / changing the styler on a >> text morph? I'll have a use for a SmaCC grammar styler as well. >> >> Anybody has a CSS parser around? >> >> Thierry >> >> >>> >>> For CSS it wouldn't be too damn hard I think. >>> >>> >>> Phil >>> >>> >>> >>> >>> >>> >>> On Fri, Sep 5, 2014 at 3:35 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: >>> >>>> Hi Torsten, Phil, >>>> >>>> On Thu, 2014-09-04 at 14:18 +0200, Torsten Bergmann wrote: >>>> > Hi Phil, >>>> > >>>> > if there is something I would like to see our Pharo ecosystem and ST >>>> in general moving >>>> > towards is to such a "multilanguage"/"multisourcecode"/"flexible >>>> ressources" kind of >>>> > thing. Even when this could not be a short term goal I would like to >>>> see this >>>> > in the long term. >>>> >>>> I've been working in this area for many years now. And have learned a >>>> good deal while doing that :-) >>>> Making one language to execute within other's environment is the easy >>>> part, though it could be a lot of work (especially, if you care about >>>> performance). Making tools to be aware of different languages is not >>>> hard too, thought it is "just" a huge amount of work that has to be >>>> done. The tricky part is to allow one to talk to each other, preserving >>>> each other's semantics and still stay intuitive, clear and free of >>>> unnecessary boilerplate code. Another tricky bit is to make other >>>> workflows and ways of coding things in other languages work nicely with >>>> the way Smalltalk way we do it in Smalltalk. These are tough bits. >>>> That's where a real research has yet to be done... >>>> >>>> > - running Java inside of Smalltalk/X >>>> >>>> Well, Smalltalk/X can do much more with Java than "just" run it. >>>> Java has been fully integrated into development tools supporting full >>>> development cycle :-) >>>> >>>> >>>> >>> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Sept. 15, 2014

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

by kilon alios

Blender indeed has its own GUI called "Ghost API" which is OpenGL 1 based in order to work even with very old GPUs. Yeap I agree with your post 100% this is why I said I love Pharo and I prefer it over any other language I have coded in. I can certainly understand your frustration with Java . I also envy you that you can use Pharo to make a living maybe I can do that one day too :) I also agree there is no such thing as silver bullet. It also depends on what you want. For example I could port Blender source base as a library to pharo with NB bindings but that would be a massive amount of work and not the same as just making small contributions to Blender. I think in the end, whether you like a programming language or not you have to be realistic about your goals and what you ask from the language. I tried to fit Pharo into my workflow but just it does not fit. The good news is that at least I will be avoiding C++ for now as the part I am most interested in Blender, sculpting is coded in C. But I dont give up on pharo just yet completely, I just said it wont be anymore my main platform. I see no reason why I should not contribute a few bug fixes or enhancements to pharo per year. I would also like to finish porting the 5th chapter of PBE to Pharo 3 at some point. So no worries I will be around, just much less active :) And will definetly follow the mailing list with great interest :) On Mon, Sep 15, 2014 at 2:24 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > FWIW, Blender has its own UI toolkit. So, they designed their own thing. > > http://3dicc.com/ 's Terf runs on Cog + internal additions. I guess it > shows that things can be done nicely when it comes to UIs. > > As for Java and UI toolkits, I've been programming in Swing very > extensively at one point. Well, as always, when you get into something very > specific, you dig into the code and see that the designers of Swing also > ran into issues and under the cover, things aren't so neat and debugging > event bubbling in these things (where then, there is suddenly *zero* doc) > is much harder with Java than with Pharo. UI is always a can of worms. Look > at all the moves from Microsoft with WinForms, Silverlight, WPF, ModernUI, > and what else... > > I've done tons of Java and Java EE. Heck, I paid my bills for years doing > that, including teaching other people on how to use it properly. Know what? > I am now sick of Java. When can we focus on the real problem and not all of > the scaffholding? Java is okay, Java has lots of APIs, Java covers a lot of > ground. But I just can't stand its ways of writing 20x more code than > needed. > > Pharo is fresh air. One can actually understand what's going on and not > merely call APIs around without understanding what's going on inside. Is it > frustrating at time, hell yes. But do I end up with better skill after > that? You bet! > > And as for C and C++ for 3D graphics, coders do use premade engines these > days, like Unreal, OGRE, or, Urho3D http://urho3d.github.io/about.html. > That last one you can script ( > http://urho3d.github.io/documentation/HEAD/_scripting.html) > > Whatever the choice or the path, it seems that massive work is needed to > get something that works semi-decently out of the door. There is no silver > bullet... > > I wish you find what you are looking for. > All the best, > Phil > > > > > On Sun, Sep 14, 2014 at 11:29 PM, kilon alios <kilon.alios(a)gmail.com> > wrote: > >> I don't plan to do anything complicated with C++ just contribute bug >> fixes to blender and maybe add a few features here and there. Definetly not >> implementing a Smalltalk into it :D I am also interesting in improving my >> mathematical knowledge about 3d graphics. I am foremost a 3d artist, but I >> like the idea of customising my own tools. I would not design anything from >> scratch since there are already tons of open source projects. Designing my >> own Smalltalk is out of the question, I prefer small projects easy to do >> and realistic / practical. >> >> Yeap I am aware of FP and Lazarus , I may play around them too but I >> will be facing the same problem I face with Pharo since they are not much >> popular either and has nothing that can compete with Blender for 3d >> graphics. I am not interested in commrecial Smalltalks from what I have >> seen Pharo looks better, maybe they have bigger libraries a bit more docs, >> but I dont think it would make much of a difference. >> >> If you are serious about coding 3d and 2d graphics , in the end knowning >> C/C++ is a big plus since most of development happens in those languages. >> >> I never said Smalltalk or Pharo is the wrong language for what I want to >> do , it was always a matter of tools and libraries. >> >> I may do something crazy like create a parser from Pharo to C++ , I think >> that would be interesting and would allow me to use Pharo for coding >> Blender source. Not a complete parser just something simple that can turn >> basic pharo syntax to C++ syntax. I would definitely being interested in >> something like this. I think Slang already does that so I may look at it >> and do maybe a few modifications here and there . >> >> I wonder if there are other parsers for Pharo to C++ , maybe a >> pettitparser template ? >> >> I would love to keep using Pharo syntax and the IDE and even keep >> contributing to it if it could generate C++ code. Actually thank you for >> reminding me about Slang :) >> >> On Mon, Sep 15, 2014 at 12:11 AM, vfclists . <vfclists(a)gmail.com> wrote: >> >>> >>> >>> On 14 September 2014 18:54, kilon alios <kilon.alios(a)gmail.com> wrote: >>> >>>> yes JAVA Swing comes with animation abilities , maybe you mean >>>> something more than that >>>> >>>> http://youtu.be/I3usNR8JrEE?t=7m41s >>>> >>>> before JAVA FX , Java had and still has Java2D. >>>> but I am no big fan of Java anyway. >>>> >>>> Dont know what it means by "ahead of its time" but back in 1998 I was >>>> coding in Delphi 1996 with a rock solid and very powerful GUI API. Delphi >>>> was an extremely powerful IDE , even more powerful than Pharo and stil is, >>>> with very mature and well documented libraries. >>>> >>>> Also if we talk about transparency animation this dates back to my days >>>> coding in DOS and C++. >>>> >>>> QT is awesome from what I see and people I ask generally have a very >>>> positive opinion about it, certainly something I may learn but my decision >>>> to swift focus from Pharo to C/C++ is not just because I having hard time >>>> coding the things I want in Pharo, its also because it makes more sense for >>>> me to contribute to Blender since my biggest interest is 3d art and blender >>>> is what I use. So re-learning C/C++ will give me full access to Blender >>>> internals which has a lot more potential for me. But yeah most likely I >>>> will learn QT and OpenGL. Its also cool that QT also supports mobile >>>> devices and even web apps. Also QML allows for live coding. >>>> >>>> I assume by 2-4 you mean full time developers. I don't know , >>>> personally I think you need more people because GUI APIs are a pain to >>>> maintain across platforms since OS define their own libraries and support. >>>> >>>> Yeap I definitely agree that Pharo needs more people using it, the >>>> problem however is that unpopularity is a vicious circle. You don't have >>>> much documentation and mature libraries because of small community and not >>>> much more new people come because you don't have much documentation and >>>> mature libraries. The problem also is fragmentation each one wants to try >>>> his own ideas and rightly so they may not be interesting in contributing to >>>> existing libraries, etc etc. These problems are common for languages. But >>>> Pharo can only get better since its in capable hands and passionate people. >>>> I have saw Pharo only improve the past year I have been using it regularly >>>> (in my free time , part time) and the community is helpful and kind if you >>>> exclude a couple of incidents here and there . >>>> >>>> About the web technology, personally I find he web is a big can of >>>> worms but a necessary evil, I always said that building pharo on top of >>>> amber would make more sense and would lift a great burden from the >>>> development of pharo. Sure pharo would inherit the problems of the web >>>> technologies and limitations but also its strengths and power and >>>> flexibility and pharo would not need to play this game of cat and mouse >>>> with other programming languages. It would at least solve the GUI API >>>> problem for Pharo and it would be a matter of mapping Spec on top of >>>> existing well documented and well tested and very powerful / flexible web >>>> technologies. >>>> >>>> But thats up to the Pharo community , my opinion is not fact and my >>>> personal choice is not the choice of other people. >>>> >>>> >>> >>> There is a saying that if you want something done, right you've got to >>> do it yourself, and this means working harder at it. Stuff like that get's >>> easier with the passage of time, but time is what you don't seem to have >>> and you may not have enough collaborators in your project. >>> >>> Seeing as you mentioned Delphi, you might consider the >>> FreePascal/Lazarus combination and consider building a Smalltalk on top if >>> it as you need a combination which gives the ease of an interpreter and >>> live coding, together with the facility to get down to the metal when you >>> need it. It also has the benefit of being crossplatform. C++ is really an >>> insane language to attempt to do something like that in. The newer >>> languages like Nimrod and Julia may be better, but they don't have the rich >>> library set you need. >>> >>> I've always felt that the design of Smalltalk/X offers a better >>> foundation for the type of stuff you want to accomplish so long as you are >>> willing to meet the conditions for using it for defense related and biotech >>> purposes. You will find the going tough as even Jan Vrany is not working on >>> it much. >>> >>> All in all I would say Smalltalk is the right language for what you want >>> to do, it is just that the free versions available don't match your exact >>> needs, both in terms of libraries and level of mass adoption. >>> >>> -- >>> Frank Church >>> >>> ======================= >>> http://devblog.brahmancreations.com >>> >> >> >

Sept. 15, 2014

WhatsUp from: 2014-09-15 until: 2014-09-30

by seaside＠rmod.lille.inria.fr

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2014-09-30 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

Sept. 15, 2014

Re: [Pharo-dev] AppeX

by Tudor Girba

Hi, As you could see in the Pillar highlighting support, Rubric can now handle any syntax highlighting in a rather straightforward way. You can also easily embed this in a Glamour browser. You can see the example in the GT-InspectorExtensions-Pillar. You can load the code in a Moose image like this: Gofer new smalltalkhubUser: 'Pier' project: 'Pillar'; configuration; loadStable. Gofer new smalltalkhubUser: 'JanKurs' project: 'PetitParser'; configurationOf: #PetitParserIslands; load. #ConfigurationOfPetitParserIslands asClass loadDevelopment. Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'GT-InspectorExtensions-Pillar'; load. Cheers, Doru On Fri, Sep 5, 2014 at 4:28 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2014-09-05 16:03 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > >> Maybe we can start small. >> >> I've current needs that could well be handled in the environment. >> >> The FileBrowser is in my view quite not used enough. >> >> When doing web applications, I deal with Javascript, CSS, content files >> etc all the time. >> >> The FileBrowser allows to edit files in its content pane. >> Doing an Accept (Alt-S) on the pane saves the file. >> >> So, instead of starting an external edit session in Vim, I mostly work >> there for some smaller changes (like tweaking CSS). >> >> Now, if we could have a syntax highlighter in there it would be nice. >> > > Yes. Anybody knows what is the API for adding / changing the styler on a > text morph? I'll have a use for a SmaCC grammar styler as well. > > Anybody has a CSS parser around? > > Thierry > > >> >> For CSS it wouldn't be too damn hard I think. >> >> >> Phil >> >> >> >> >> >> >> On Fri, Sep 5, 2014 at 3:35 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: >> >>> Hi Torsten, Phil, >>> >>> On Thu, 2014-09-04 at 14:18 +0200, Torsten Bergmann wrote: >>> > Hi Phil, >>> > >>> > if there is something I would like to see our Pharo ecosystem and ST >>> in general moving >>> > towards is to such a "multilanguage"/"multisourcecode"/"flexible >>> ressources" kind of >>> > thing. Even when this could not be a short term goal I would like to >>> see this >>> > in the long term. >>> >>> I've been working in this area for many years now. And have learned a >>> good deal while doing that :-) >>> Making one language to execute within other's environment is the easy >>> part, though it could be a lot of work (especially, if you care about >>> performance). Making tools to be aware of different languages is not >>> hard too, thought it is "just" a huge amount of work that has to be >>> done. The tricky part is to allow one to talk to each other, preserving >>> each other's semantics and still stay intuitive, clear and free of >>> unnecessary boilerplate code. Another tricky bit is to make other >>> workflows and ways of coding things in other languages work nicely with >>> the way Smalltalk way we do it in Smalltalk. These are tough bits. >>> That's where a real research has yet to be done... >>> >>> > - running Java inside of Smalltalk/X >>> >>> Well, Smalltalk/X can do much more with Java than "just" run it. >>> Java has been fully integrated into development tools supporting full >>> development cycle :-) >>> >>> >>> >> > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 15, 2014

Re: [Pharo-dev] GToolkit

by Esteban A. Maringolo

2014-09-14 15:53 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi Phil, > It would be cool to know the reasons why people have to use other tools. > Perhaps we can do something about it. If it involves text edition or manipulation, I use external tools because of the lack of certain features in Pharo workspaces (or even syntax highlighting limits) or due to the comfort I find in using the same key bindings/shortcuts I use everywhere to edit a csv file, SQL script, chunk or whatever. That's one of the reasons. :) Another one is that I found the option to do things externally to be "safer" than relying on a unique tool to do all the tasks. "Rule of Composition" and "Rule of Modularity" according to the Unix Philosophy. Not to mention the "Rule of Parsimony": Write a big program only when it is clear by demonstration that nothing else with do. :) Regards! Esteban A. Maringolo

Sept. 15, 2014