October 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] The Ultimate Smalltalk Tutorial

by Vitor Medina Cruz

I think the MOOC is too much for a tutorial. What I miss today is a good written (no videos! Please!) tutorial that teaches just a little of the language and give a few guidelines on how to do simple stuff with the environment, such as a "Hello World!", creating a class, tests and run stuff. On Sat, Oct 15, 2016 at 12:15 PM, horrido <horrido.hobbies(a)gmail.com> wrote: > Excellent suggestion! I shall look into it. Thanks. > > > > > -- > View this message in context: http://forum.world.st/The- > Ultimate-Smalltalk-Tutorial-tp4918859p4918930.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Oct. 23, 2016

Re: [Pharo-users] Other format to Filetree

by Vitor Medina Cruz

It is usually a small project, for code fragments I just shared as text and it was easy for people to understand. On Sat, Oct 22, 2016 at 1:31 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > and if you want to copy the text to the clipboard so you can paste it > anywhere, for example gist, pastebin etc add the following command in the > end of the script i gave you > > Clipboard clipboardText: source. > > On Sat, Oct 22, 2016 at 6:24 PM Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > >> if we are talking a code fragment , say a few dozen lines of code then do >> the following: >> >> 1) Open the Playground >> 2) Type : Transcript open. Transcript show: 'hello world'. >> 3) Press the Remote publish button ( next to green triangle icon) >> 4) will give you a link and will paste the link to your keyboard >> 5) profit ! >> >> in my case >> >> http://ws.stfx.eu/HYOEJ3B0WJH9 >> >> If you feel adventurous and you want to send the source code of a class >> directly to the playground , including all its instance and class methods , >> in order to remotely publish it , you can make a method that does this >> using this code >> >> source :=''. >> targetClass:= Transcript. >> source := source,String cr,'"--------Instance >> Methods------------"',String cr. >> targetClass class methods do: [:each| source := source , (each >> sourceCode), String cr,'"-----------------------------"', String cr]. >> source := source,String cr,'"--------Class Methods------------"',String >> cr. >> targetClass class class methods do: [:each| source := source , (each >> sourceCode), String cr,'"-----------------------------"', String cr]. >> x:= GTPlayground openContents: source. >> >> >> On Sat, Oct 22, 2016 at 5:19 PM Vitor Medina Cruz <vitormcruz(a)gmail.com> >> wrote: >> >> Thanks for the answers! >> >> Charlie: It happens that most people are not willing to download the >> environment, no matter how many times you tell and explain that it is dead >> simple, before look at some code and discuss solutions, so this becomes a >> barrier for them to look further in the Smalltalk world.This is not >> exclusive for Smalltalk, I am in a discussion group that people program in >> Java, Scala, Go, Clojure and Ruby, and no one wants to set up an >> environment of a foreign language before peeking at some code. >> >> Dimitris: I like your idea, I will think in something in these lines if >> fileout don't work. >> >> Dale: Wow! A SmalltalkBrowser in web for Filetree would be awesome! In >> the mean time I think file-per-class, as described Martin, would just do >> the trick. :) >> >> If fileout do the trick I will let you know :) >> >> Thanks you all! >> Vitor >> >> On Sat, Oct 22, 2016 at 10:49 AM, Dale Henrichs < >> dale.henrichs(a)gemtalksystems.com> wrote: >> >> This is a good suggestion ... along these lines I've always thought that >> it would make a lot of sense to write a SmalltalkBrowser for Github in >> Amber of PHaroJS that would read Filetree package structure and display it >> the "right way" ... For extra credit one could even edit code in the >> browser:) >> >> And of course, the SmalltalkBrowser shouldn't be limited to just GitHub >> ... >> >> I wish that I had the spare cycles to do this:) >> >> Dale >> >> On 10/21/16 6:06 PM, Charlie Robbats wrote: >> >> I'd like to suggest you teach people Smalltalk natively, so they don't >> get distracted by the false view of a filetree of classes. One huge >> differentiator of Smalltalk, from any other language out there, is the >> live object environment. You should use that environment to teach from or >> the nuance will be lost and they may well give up. Consider, is there any >> Java IDE that allows any expression anywhere to be evaluated and inspected >> with a mouse click or shortcut? So host your mcz on github but provide an >> install doc to have them install Pharo and load your code, for the lessons. >> They will look at Smalltalk code naturally in Pharo browsers and be exposed >> to an IDE they have never before experienced, as well. In the process you >> can webinar your navigations that they can follow along. Nebraska around? >> Those who consider it worthy will stay. Keep doing what you are doing! >> >> Charlie >> >> On 10/21/2016 8:51 PM, Vitor Medina Cruz wrote: >> >> Thank you for the answers! Actually my question has a rather silly >> reason: I find it difficult to navigate and peek at code in the current >> format. I would like to show ST code to other people through GitHub â it is >> pretty common for me to discuss implementations of katas, for example, from >> multiple platforms only looking at the GitHub project â, but the format get >> in the way. People usually give up of looking it because it is hard to >> navigate through the directory tree and understand all the separate pieces >> as a whole, and so I must explain my solution verbally and people get >> suspicious of ST and unwilling to try the environment for the first time. >> :( >> >> I think I am going to commit a fileout of the project, maybe people will >> find easier to peek at. Do you have other suggestion? >> >> Thanks! >> Vitor >> >> On Fri, Oct 21, 2016 at 4:36 PM, Dimitris Chloupis <kilon.alios(a)gmail.com >> > wrote: >> >> Do you have something specific in your mind ? >> >> What are your needs and desires for an alternate Filetree format ? What >> you want to see changed in Filetreee ? >> >> >> On Fri, Oct 21, 2016 at 7:02 PM Vitor Medina Cruz <vitormcruz(a)gmail.com> >> wrote: >> >> Hello, >> >> I was wondering: is there another format available for Filetree? >> >> Regards, >> Vitor >> >> >> >> >> >>

Oct. 23, 2016

Re: [Pharo-users] What is the correct way to go around implementing a GUI feature in Pharo?

by Dimitris Chloupis

its possible also to use Bootstrap directly, Pharo can use html and js as its GUI. Actually in pharo website, the vast majority of pharo apps are web apps and so they use HTML5/JS for their GUI or any compatible technology. I use Morphic as basis for my GUIs, generally I avoid the higher level classes because they tend to have messy implementation and recreate them myself choosing a design and api that makes sense to me. Its surprisingly easy but under the condition that you make simple GUI elements, like buttons, custom text fields etc. Something more sophisticated obviously will be harder to make. Morphic is as beautiful at its low level parts as it is ugly for its high level parts. Also the paradox with Morphic is that you may find zero documentation for its more recent features which are mainly higher level gui elements but for its old stuff , there is plenty. for example http://handbook.selflanguage.org/current/morphic.html http://wiki.squeak.org/squeak/morphic Warning: Documentation may be outdated Alternative solutions do exist , Spec is the obviously third most favourite after HTML5/JS and Morphic and its very well documented, its has the advantage that it can covert with easy morphic to spec gui elements so what you learn for Morphic you can carry it on to Spec. On the experimental front you could go for any well known IDE and use an IPC method. I have played around with Pharo and QT and I have made it work through my python bridge but never took it very seriously and I only did only the most basic experiments. Of course because what I executed was python code from Pharo there was very little reason for it not to work. The disadvantage is that you have to know Python , a language which is extremely useful to know anyway because of its immense popularity, and QT, and understand how sockets work, regular expression parsing and SmaCC. The good news is that all of the above are well documented but still its a steep learning curve. The advantages will be that you will be using a super powerful , high performance GUI API like QT and with the added bonus that you will have available to you QTCreator as a GUI designer a tool that pharo severely misses. If you are aiming for a very powerful , difficult and complex GUI that must be super high performance, this is really a very good choice. The same approach of IPC (socket based in my case) can work for any other language and any other library which means you can use any GUI API of any language under any platform. Even HTML/JS GUIs for Pharo use a similar approach with websockets, so its pretty much a well tested method. GTK, Cocoa, Winforms, WxWidgets and a ton of other GUI APIs are at your fingertips. If you prefer to stick with Pharo all the way and love cutting edge sharper than a katana, then Bloc becomes a viable options but remember , its called "cutting edge" because it can easily cut you up in pieces so arm yourself with patience and resilience. On Sun, Oct 23, 2016 at 8:02 AM CodeDmitry <dimamakhnin(a)gmail.com> wrote: > I want to have a bootstrap-like navbar at the top of my pharo GUI to store > commonly accessed features/custom hierarchies of menus. > > My first thought is that I should spend a bunch of time playing with Morphs > and invent my own MVC(models being the state managed by the menu, views > being the controls(morphs), and controllers being asynchronous blocks of > code that are invoked when events occur). > > Are there any good resources that teach how to go around doing stuff like > this, or do I have to reinvent it myself by researching how Pharo GUI works > internally, and figure out how to do this by successful incremental > experiments? > > > > > > -- > View this message in context: > http://forum.world.st/What-is-the-correct-way-to-go-around-implementing-a-G… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Oct. 23, 2016

Re: [Pharo-users] What is the correct way to go around implementing a GUI feature in Pharo?

by Nicolai Hess

2016-10-23 11:07 GMT+02:00 Stephan Eggermont <stephan(a)stack.nl>: > On 23/10/16 06:53, CodeDmitry wrote: > >> Are there any good resources that teach how to go around doing stuff like >> this, or do I have to reinvent it myself by researching how Pharo GUI >> works >> internally, and figure out how to do this by successful incremental >> experiments? >> > > This mostly just assembles and configures a number of existing parts. Take > a look at DockingBarMorph & friends. > Another example, if the menu should be per app window and not per pharo window, look at the ApplicationWithToolbar example. > > Stephan > > > >

Oct. 23, 2016

Re: [Pharo-users] What is the correct way to go around implementing a GUI feature in Pharo?

by Stephan Eggermont

On 23/10/16 06:53, CodeDmitry wrote: > Are there any good resources that teach how to go around doing stuff like > this, or do I have to reinvent it myself by researching how Pharo GUI works > internally, and figure out how to do this by successful incremental > experiments? This mostly just assembles and configures a number of existing parts. Take a look at DockingBarMorph & friends. Stephan

Oct. 23, 2016

Re: [Pharo-users] Glamorous Toolkit as IDE for another language?

by Stephan Eggermont

On 22/10/16 11:47, Luke Gorrie wrote: > Howdy, > > I am interested in building a Lua IDE using the Glamorous Toolkit. The > idea is that the Playground, the Inspector, the Spotter, and the > Debugger would all be interacting with an external Lua process instead > of running code in the Pharo image. The "under the hood" part of Pharo - > Smalltalk code - would be hidden unless specially enabled. > > Good or bad idea? Any tips on how to approach this? Has something > similar been done before? (Is there example code available?) Definitely a good idea. The toolkit is up to it, and probably still contains a few places where it is bound too tightly to smalltalk. I have integrated documentation and workshop exercises in a glamour browser. In my UI experiments I've bound Spotter for different purposes (selecting a person from an addressbook). The idea goes back a long time. In Squeak, the PostgresV3 integration allows editing of pgsql stored procedures in the code browser. Stephan

Oct. 23, 2016

Re: [Pharo-users] What is the correct way to go around implementing a GUI feature in Pharo?

by phil＠highoctane.be

You can have a look at the Tiling Window Manager which is having those things. Now it is broken in Pharo5 and there is something wrong with the world menu in it. The image locks up and it is not that pleasant to debug. It works, except from the World menu thing (due to changes in the World / PasteUpMorph refactoring). [image: Inline image 1] I'll remove the World entry so that you can try in Pharo5. Phil On Sun, Oct 23, 2016 at 6:53 AM, CodeDmitry <dimamakhnin(a)gmail.com> wrote: > I want to have a bootstrap-like navbar at the top of my pharo GUI to store > commonly accessed features/custom hierarchies of menus. > > My first thought is that I should spend a bunch of time playing with Morphs > and invent my own MVC(models being the state managed by the menu, views > being the controls(morphs), and controllers being asynchronous blocks of > code that are invoked when events occur). > > Are there any good resources that teach how to go around doing stuff like > this, or do I have to reinvent it myself by researching how Pharo GUI works > internally, and figure out how to do this by successful incremental > experiments? > > > > > > -- > View this message in context: http://forum.world.st/What-is- > the-correct-way-to-go-around-implementing-a-GUI-feature-in- > Pharo-tp4919772.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > >

Oct. 23, 2016

What is the correct way to go around implementing a GUI feature in Pharo?

by CodeDmitry

I want to have a bootstrap-like navbar at the top of my pharo GUI to store commonly accessed features/custom hierarchies of menus. My first thought is that I should spend a bunch of time playing with Morphs and invent my own MVC(models being the state managed by the menu, views being the controls(morphs), and controllers being asynchronous blocks of code that are invoked when events occur). Are there any good resources that teach how to go around doing stuff like this, or do I have to reinvent it myself by researching how Pharo GUI works internally, and figure out how to do this by successful incremental experiments? -- View this message in context: http://forum.world.st/What-is-the-correct-way-to-go-around-implementing-a-G… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Oct. 23, 2016

Re: [Pharo-users] image shrinking and cleanup

by Ben Coman

Spur has a known poor compaction algorithm that I understand from past vm-dev posts is near the top of the list for next action. For the moment you might try Spur32BitPreen... * http://forum.world.st/unused-method-removal-vs-Spur-compaction-td4916008.ht… * http://forum.world.st/Fwd-Vm-dev-unused-method-removal-vs-Spur-compaction-t… * http://forum.world.st/VM-Maker-Cog-eem-328-mcz-td4911122.html cheers -ben On Sat, Oct 22, 2016 at 7:43 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > Hi, > > I know that I can cleanup the image with `Smalltalk cleanUp: true except: {} confirming: false.`, however that doesn't seem to help much. > My guess is that there are some objects that the system is permanently unable to GC, however I have no idea how to find them (or even where to begin the search). > > Just as a note, the size of the image by itself is not an issue (I have plenty of disk space), however it is severly slowing down image saving. > > I remember that there was some issue with image shrinking, but I am not sure what is the state of that. > > Oh, and I am using Pharo 5. > > Thanks, > Peter >

Oct. 23, 2016

Re: [Pharo-users] Glamorous Toolkit as IDE for another language?

by Offray Vladimir Luna CÃ¡rdenas

Hi Luke, It seems like a good idea to me. I'm implementing an outliner+notebook alike interface for integrating interactive documentation, data visualization and exploratory computing, called Grafoscopio [1] (available from the Pharo Catalog) and would be really nice to have something like the Jupyter[2] kernels talking with several languages, supported in the playgrounds. That would be a good start to increase the diversity of languages supported in interactive documents [1] http://mutabit.com/grafoscopio/index.en.html [2] http://jupyter.org/ Welcome and let me know if this idea of multilingual (code & prose) interactive documents rings a bell for you. Cheers, Offray PS: By the way, Ben, if you're reading this, my migration of Grafoscopio to the Spec+Glamour interface is going well and now you can test the notebooks. I'm open to feedback. Next week we will start our 7th edition of our Data Week hackathon + workshop, this time for intermediate level apprentices, that have the experience with previous Data Weeks. On 22/10/16 04:47, Luke Gorrie wrote: > Howdy, > > I am interested in building a Lua IDE using the Glamorous Toolkit. The > idea is that the Playground, the Inspector, the Spotter, and the > Debugger would all be interacting with an external Lua process instead > of running code in the Pharo image. The "under the hood" part of Pharo > - Smalltalk code - would be hidden unless specially enabled. > > Good or bad idea? Any tips on how to approach this? Has something > similar been done before? (Is there example code available?) > > Cheers, > -Luke > >

Oct. 22, 2016