Hi, This is my first week with Pharo. I have been moderately successful in learning how things go, but I cannot seem to create a HELP|ABOUT dialog. Pointing me in the right direction would be appreciated. Thanks. Bruce
Hi Bruce, This is my first week in a LONG time too, so good luck! If you open a Finder (Tools->Finder), and search for "about" (selectors), you will find a bunch of things that respond to "aboutText", like "SystemWindow," and "ComposableModel." The little drop-down arrow in the upper right of these system windows has an "about" item in the menu, and I just tried adding and aboutText method to the Spec Example "ApplicationWithToolbar" and the about box displayed the text I returned from that method. I hope that helps, and maybe we'll both be able to figure some things out! Take care, Rob
On Apr 10, 2016, at 6:44 PM, Bruce Peaslee <bruceapeaslee@comcast.net> wrote:
This is my first week with Pharo. I have been moderately successful in learning how things go, but I cannot seem to create a HELP|ABOUT dialog. Pointing me in the right direction would be appreciated.
Also, this default behavior can be reproduced with: (LongMessageDialogWindow new entryText: 'Hello') open (well, that doesn't set the title to "About"...) I just can't figure out how to set the text for non-"long message" dialogs! Take care, Rob
On Apr 10, 2016, at 6:44 PM, Bruce Peaslee <bruceapeaslee@comcast.net <mailto:bruceapeaslee@comcast.net>> wrote:
This is my first week with Pharo. I have been moderately successful in learning how things go, but I cannot seem to create a HELP|ABOUT dialog. Pointing me in the right direction would be appreciated.
On Apr 10, 2016, at 6:44 PM, Bruce Peaslee <bruceapeaslee@comcast.net> wrote:
This is my first week with Pharo. I have been moderately successful in learning how things go, but I cannot seem to create a HELP|ABOUT dialog. Pointing me in the right direction would be appreciated.
Also my first week with Pharo, and first week with Smalltalk in over 20 years. On 11 April 2016 at 02:07, Robert J Rothwell <r.j.rothwell@gmail.com> wrote:
Also, this default behavior can be reproduced with:
(LongMessageDialogWindow new entryText: 'Hello') open
(well, that doesn't set the title to "About"...)
LongMessageDialogWindow new entryText: 'Hello World'; title: 'About'; open I figured this one out by changing the browser to class hierarchy and walking up through the classes until I found a likely method (title:). Cheers, Alistair
On Mon, Apr 11, 2016 at 8:57 AM, Alistair Grant <akgrant0710@gmail.com> wrote:
On Apr 10, 2016, at 6:44 PM, Bruce Peaslee <bruceapeaslee@comcast.net> wrote:
This is my first week with Pharo. I have been moderately successful in learning how things go, but I cannot seem to create a HELP|ABOUT dialog. Pointing me in the right direction would be appreciated.
Also my first week with Pharo, and first week with Smalltalk in over 20 years.
Congrats ! Tell us what is your experience until now ;-) -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
Hi Serge, On Mon, Apr 11, 2016 at 09:46:02AM +0200, Serge Stinckwich wrote:
On Mon, Apr 11, 2016 at 8:57 AM, Alistair Grant <akgrant0710@gmail.com> wrote:
Also my first week with Pharo, and first week with Smalltalk in over 20 years.
Congrats ! Tell us what is your experience until now ;-)
I was the technical lead of a team that programmed with VisualWorks 2.5 for several years in the 90's, porting it to VMS (VAX and Aplha) and writing a real-time graphical interface for monitoring and controlling the water distribution in one of the capital cities in Australia (Brisbane). The UI allowed users to build a library of widgets from basic shapes, e.g. valves, pumps, reservoirs, etc. They could then be built up to schematics and attached to a real-time database, receiving events whenever a value changed. E.g. valves would change shape or colour depending on whether they were open or closed, alarms would flash, a pump would show its flow rate, etc. We tested it receiving up to 1200 events per second (this was in the days when a 100MHz RISC processor was the best available (from memory)). All the graphics, event management and query optimisation were in Smalltalk, the database query execution and event delivery was in C (the database was in-memory and didn't support any query language, that all had to be done by the client). I left the company a year or so later. I heard that it was replaced some years after I left, but I'm not sure when that happened. Cheers, Alistair
Thank you. I was talking about your experience with Pharo :-) But your description is nice also. Regards, On Mon, Apr 11, 2016 at 8:40 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Serge,
On Mon, Apr 11, 2016 at 09:46:02AM +0200, Serge Stinckwich wrote:
On Mon, Apr 11, 2016 at 8:57 AM, Alistair Grant <akgrant0710@gmail.com> wrote:
Also my first week with Pharo, and first week with Smalltalk in over 20 years.
Congrats ! Tell us what is your experience until now ;-)
I was the technical lead of a team that programmed with VisualWorks 2.5 for several years in the 90's, porting it to VMS (VAX and Aplha) and writing a real-time graphical interface for monitoring and controlling the water distribution in one of the capital cities in Australia (Brisbane).
The UI allowed users to build a library of widgets from basic shapes, e.g. valves, pumps, reservoirs, etc. They could then be built up to schematics and attached to a real-time database, receiving events whenever a value changed. E.g. valves would change shape or colour depending on whether they were open or closed, alarms would flash, a pump would show its flow rate, etc.
We tested it receiving up to 1200 events per second (this was in the days when a 100MHz RISC processor was the best available (from memory)). All the graphics, event management and query optimisation were in Smalltalk, the database query execution and event delivery was in C (the database was in-memory and didn't support any query language, that all had to be done by the client).
I left the company a year or so later. I heard that it was replaced some years after I left, but I'm not sure when that happened.
Cheers, Alistair
-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
On Mon, Apr 11, 2016 at 09:02:52PM +0200, Serge Stinckwich wrote:
Thank you. I was talking about your experience with Pharo :-) But your description is nice also.
Ahh, right, sorry about that. Pharo 5.0 first impressions from someone coming from VW2.5... I'm already a fan of Smalltalk and its development environment. I've only spent a few hours working with Pharo (it's my hobby, with not nearly as much time as I would like): * I read the first few chapters of Pharo by Example as an introduction to Pharo. * The browser, debugger and basic inspectors are all familiar enough that I was able to work with them without any issues. * I'm glad that being able to run headless mode is easy, as I'd like to use Pharo for scripting. * The addition of Montacello / Metacello / Gofer and SUnit are the biggest improvements I've noticed so far. I wish I had these 20 years ago. * I've only played with the MessageFlow Browser a little, but I think it will be one of my go-to tools. * I'm still getting used to the idea of the entire ST environment being in a single OS window, but at the moment I think I prefer VW's approach where each ST window is a OS window, as it makes it easier to work with other applications, e.g. if I want to look at an email or web page while working within ST. I only have one suggested improvement so far (assuming it doesn't already exist and I just haven't found it yet)... When searching for packages on SqueakSource / SmalltalkHub etc. it isn't clear to me how much confidence I can have in any given package, which is really useful if there are multiple packages providing similar functionality. The Arch Linux model seems pretty good to me. Official packages are in the core or extra repositories, which matches what is included in the Pharo image. The next level is a community repository, which contains packages maintained by Trusted Users. General users can be confident that these packages will be kept up to date. The last level is the User Repository (AUR), which anyone can contribute to. The AUR includes a comment section and vote count, and general users can add or remove their vote. Hope I haven't ruffled too many feathers... Thanks! Alistair
On 12-04-16 19:51, Alistair Grant wrote:
I only have one suggested improvement so far (assuming it doesn't already exist and I just haven't found it yet)... When searching for packages on SqueakSource / SmalltalkHub etc. it isn't clear to me how much confidence I can have in any given package, which is really useful if there are multiple packages providing similar functionality.
One of our community tools for that is a continuous integration server: http://ci.inria.fr/pharo-contribution. There several of these configurations are build and tested, often against several Pharo versions. Several Pharo users are also already using TravisCI and github for that. Stephan
Le 12/4/16 19:51, Alistair Grant a écrit :
On Mon, Apr 11, 2016 at 09:02:52PM +0200, Serge Stinckwich wrote:
Thank you. I was talking about your experience with Pharo :-) But your description is nice also. Ahh, right, sorry about that.
Pharo 5.0 first impressions from someone coming from VW2.5...
I'm already a fan of Smalltalk and its development environment. I've only spent a few hours working with Pharo (it's my hobby, with not nearly as much time as I would like):
* I read the first few chapters of Pharo by Example as an introduction to Pharo. * The browser, debugger and basic inspectors are all familiar enough that I was able to work with them without any issues.
You should have a look at the inspector Inspect Point>>#x to see what I mean and look at the tabs
* I'm glad that being able to run headless mode is easy, as I'd like to use Pharo for scripting. Me too. We are starting a new iteration on this. We got a student whose job is to convert bash script to pharo and identify problem so if you want to share effort you are welcome.
* The addition of Montacello / Metacello / Gofer and SUnit are the biggest improvements I've noticed so far. I wish I had these 20 years ago. * I've only played with the MessageFlow Browser a little, but I think it will be one of my go-to tools. * I'm still getting used to the idea of the entire ST environment being in a single OS window, but at the moment I think I prefer VW's approach where each ST window is a OS window, as it makes it easier to work with other applications, e.g. if I want to look at an email or web page while working within ST. In the future you will be able to choose between one window
I only have one suggested improvement so far (assuming it doesn't already exist and I just haven't found it yet)... When searching for packages on SqueakSource / SmalltalkHub etc. it isn't clear to me how much confidence I can have in any given package, which is really useful if there are multiple packages providing similar functionality.
I hope that soon we will have a package validation in place.
The Arch Linux model seems pretty good to me. Official packages are in the core or extra repositories, which matches what is included in the Pharo image. The next level is a community repository, which contains packages maintained by Trusted Users. General users can be confident that these packages will be kept up to date. The last level is the User Repository (AUR), which anyone can contribute to. The AUR includes a comment section and vote count, and general users can add or remove their vote.
You get a bit of that in the catalog browser.
Hope I haven't ruffled too many feathers...
Thanks! Alistair
On Tue, Apr 12, 2016 at 09:28:07PM +0200, stepharo wrote:
Le 12/4/16 19:51, Alistair Grant a écrit :
* I'm glad that being able to run headless mode is easy, as I'd like to use Pharo for scripting. Me too. We are starting a new iteration on this. We got a student whose job is to convert bash script to pharo and identify problem so if you want to share effort you are welcome.
I'd be happy to, thanks. Please let me know what I need to do to get involved (and remember that this is my hobby and I don't get as much time as I'd like, so my responses won't always be as fast as we'd like). Thanks! Alistair P.S. I'm still putting together my response to all the other comments in this thread.
I'd be happy to, thanks. Please let me know what I need to do to get involved (and remember that this is my hobby and I don't get as much time as I'd like, so my responses won't always be as fast as we'd like).
- start to see if you can write the scripts you want. - identify missing functionality - use OSSubprocess
Thanks! Alistair
P.S. I'm still putting together my response to all the other comments in this thread.
On Wed, Apr 13, 2016 at 05:55:22PM +0200, stepharo wrote:
I'd be happy to, thanks. Please let me know what I need to do to get involved (and remember that this is my hobby and I don't get as much time as I'd like, so my responses won't always be as fast as we'd like).
- start to see if you can write the scripts you want. - identify missing functionality - use OSSubprocess
Sure... While the existing "st" handler has some uses, I think it will be a bit limited as I expect that most of the scripts I would write would end up being: 1. Load required packages 2. Maybe do some initialisation 3. Send (basically) a single message to start the real work Which means that I have to maintain a separate file that adds little value. As implied above, I'd like the "script" to be distributable as either one or two files and take advantage of: * OO design * Pharo's excellent development environment * SUnit I've hacked together a quick framework in which a "script" is actually a a Monticello package. The package name is supplied on the command line along with some pre-defined options and anything else required by the script. The package is loaded and a message sent to the class of the same name. E.g.: pharo script.image cliscript WorkedHours Hours.xlsx would load ConfigurationOfWorkedHours, load the package, and send WorkedHours>>runWithHandler: theCliHandler. (The example script then reads the Hours spreadsheet and calculates the total hours worked). Current help text...
./pharo script.image cliscript --help CliScript enables running "Monticello" scripts.
The script is identified by its package name. CliScript looks for a configuration package with the same name in the local package cache, loads it, and sends the runWithHandler: message to the class with the same name. Command line parameters: packageName The package to load and execute. Command line options: --debug Halt at the start of the message --log-transcript Redirect transcript output to transcript.log I haven't had to use OSSubprocess yet, next steps include: * Read XSLX spreadsheets instead of having to export to CSV. The script mostly does date and time calculations, I need to confirm that they are working properly in Tabular. * Add logging (I haven't looked for any logging capability yet). * Ideally, implement the ODS support in the Tabular package (stretch goal :-)). Thanks! Alistair
Have a look at the chapter about command handler in Deep into Pharo because you have all you need You can script the loading and execution of expressions easily. People like julien, damien at Pharodays started to resume a better DSL for command descriptions. Le 13/4/16 19:48, Alistair Grant a écrit : > On Wed, Apr 13, 2016 at 05:55:22PM +0200, stepharo wrote: >>> I'd be happy to, thanks. Please let me know what I need to do to get >>> involved (and remember that this is my hobby and I don't get as much >>> time as I'd like, so my responses won't always be as fast as we'd like). >> - start to see if you can write the scripts you want. >> - identify missing functionality >> - use OSSubprocess > Sure... > > While the existing "st" handler has some uses, I think it will be a bit > limited as I expect that most of the scripts I would write would end up > being: > > 1. Load required packages > 2. Maybe do some initialisation > 3. Send (basically) a single message to start the real work > > Which means that I have to maintain a separate file that adds little > value. > > As implied above, I'd like the "script" to be distributable as either > one or two files and take advantage of: > > * OO design > * Pharo's excellent development environment > * SUnit > > I've hacked together a quick framework in which a "script" is actually a > a Monticello package. The package name is supplied on the command line > along with some pre-defined options and anything else required by the > script. The package is loaded and a message sent to the class of the > same name. E.g.: > > pharo script.image cliscript WorkedHours Hours.xlsx > > would load ConfigurationOfWorkedHours, load the package, and > send WorkedHours>>runWithHandler: theCliHandler. (The example script > then reads the Hours spreadsheet and calculates the total hours worked). > > Current help text... > >> ./pharo script.image cliscript --help > CliScript enables running "Monticello" scripts. > > The script is identified by its package name. CliScript looks for a > configuration package with the same name in the local package cache, > loads it, and sends the runWithHandler: message to the class with the > same name. > > Command line parameters: > > packageName The package to load and execute. > > Command line options: > > --debug Halt at the start of the message > --log-transcript Redirect transcript output to transcript.log > > > > I haven't had to use OSSubprocess yet, next steps include: > > * Read XSLX spreadsheets instead of having to export to CSV. > The script mostly does date and time calculations, I need to confirm > that they are working properly in Tabular. > * Add logging (I haven't looked for any logging capability yet). > * Ideally, implement the ODS support in the Tabular package (stretch > goal :-)). > > > Thanks! > Alistair > >
On Thu, Apr 14, 2016 at 08:37:39AM +0200, stepharo wrote:
Have a look at the chapter about command handler in Deep into Pharo because you have all you need
You can script the loading and execution of expressions easily.
People like julien, damien at Pharodays started to resume a better DSL for command descriptions.
Thanks. I had started reading Pharo by Example, but it looks like Deep into Pharo is more up to date. Thanks again, Alistair
On Saturday, 16 April 2016, Alistair Grant <akgrant0710@gmail.com> wrote:
Thanks. I had started reading Pharo by Example, but it looks like Deep into Pharo is more up to date.
A new version of PBE is almost ready. You can find it at https://ci.inria.fr/pharo-contribution/view/Books/job/UpdatedPharoByExample/... . Other formats https://ci.inria.fr/pharo-contribution/view/Books/job/UpdatedPharoByExample/... <https://ci.inria.fr/pharo-contribution/view/Books/job/UpdatedPharoByExample/...>
Thanks again, Alistair
From my phone~~
-- Cheers Cyril Ferlicot
On Sat, Apr 16, 2016 at 01:43:29PM +0200, Cyril Ferlicot wrote:
A new version of PBE is almost ready. You can find it at https://ci.inria.fr/ pharo-contribution/view/Books/job/UpdatedPharoByExample/lastSuccessfulBuild/ artifact/book-result/UpdatedPharoByExample.pdf . Other formats https://ci.inria.fr/pharo-contribution/view/Books/job/ UpdatedPharoByExample/lastSuccessfulBuild/artifact/book-result
Are you looking for feedback? Thanks, Alistair
Le 17/4/16 10:01, Alistair Grant a écrit :
On Sat, Apr 16, 2016 at 01:43:29PM +0200, Cyril Ferlicot wrote:
A new version of PBE is almost ready. You can find it at https://ci.inria.fr/ pharo-contribution/view/Books/job/UpdatedPharoByExample/lastSuccessfulBuild/ artifact/book-result/UpdatedPharoByExample.pdf . Other formats https://ci.inria.fr/pharo-contribution/view/Books/job/ UpdatedPharoByExample/lastSuccessfulBuild/artifact/book-result Are you looking for feedback?
Yes but mainly english typos because I do not have the energy to do more and the book should get out. By the end of the month. Stef
Thanks, Alistair
On Sun, Apr 17, 2016 at 09:53:55PM +0200, stepharo wrote:
Le 17/4/16 10:01, Alistair Grant a écrit :
On Sat, Apr 16, 2016 at 01:43:29PM +0200, Cyril Ferlicot wrote:
A new version of PBE is almost ready. You can find it at https://ci.inria.fr/ pharo-contribution/view/Books/job/UpdatedPharoByExample/lastSuccessfulBuild/ artifact/book-result/UpdatedPharoByExample.pdf . Other formats https://ci.inria.fr/pharo-contribution/view/Books/job/ UpdatedPharoByExample/lastSuccessfulBuild/artifact/book-result Are you looking for feedback?
Yes but mainly english typos because I do not have the energy to do more and the book should get out. By the end of the month.
OK, I'll look at this first (with limited time) and if I happen to see anything will report back. Thanks, Alistair
On Apr 12, 2016, at 10:51, Alistair Grant <akgrant0710@gmail.com> wrote:
On Mon, Apr 11, 2016 at 09:02:52PM +0200, Serge Stinckwich wrote: Thank you. I was talking about your experience with Pharo :-) But your description is nice also.
Ahh, right, sorry about that.
Pharo 5.0 first impressions from someone coming from VW2.5...
I'm already a fan of Smalltalk and its development environment. I've only spent a few hours working with Pharo (it's my hobby, with not nearly as much time as I would like):
* I read the first few chapters of Pharo by Example as an introduction to Pharo. * The browser, debugger and basic inspectors are all familiar enough that I was able to work with them without any issues. * I'm glad that being able to run headless mode is easy, as I'd like to use Pharo for scripting. * The addition of Montacello / Metacello / Gofer and SUnit are the biggest improvements I've noticed so far. I wish I had these 20 years ago. * I've only played with the MessageFlow Browser a little, but I think it will be one of my go-to tools. * I'm still getting used to the idea of the entire ST environment being in a single OS window, but at the moment I think I prefer VW's approach where each ST window is a OS window, as it makes it easier to work with other applications, e.g. if I want to look at an email or web page while working within ST.
I only have one suggested improvement so far (assuming it doesn't already exist and I just haven't found it yet)... When searching for packages on SqueakSource / SmalltalkHub etc. it isn't clear to me how much confidence I can have in any given package, which is really useful if there are multiple packages providing similar functionality.
The Arch Linux model seems pretty good to me. Official packages are in the core or extra repositories, which matches what is included in the Pharo image. The next level is a community repository, which contains packages maintained by Trusted Users. General users can be confident that these packages will be kept up to date. The last level is the User Repository (AUR), which anyone can contribute to. The AUR includes a comment section and vote count, and general users can add or remove their vote.
I'd like to see something like this too.
Hope I haven't ruffled too many feathers...
Thanks! Alistair
Le 13/4/16 06:48, John Pfersich a écrit :
On Apr 12, 2016, at 10:51, Alistair Grant <akgrant0710@gmail.com> wrote:
On Mon, Apr 11, 2016 at 09:02:52PM +0200, Serge Stinckwich wrote: Thank you. I was talking about your experience with Pharo :-) But your description is nice also. Ahh, right, sorry about that.
Pharo 5.0 first impressions from someone coming from VW2.5...
I'm already a fan of Smalltalk and its development environment. I've only spent a few hours working with Pharo (it's my hobby, with not nearly as much time as I would like):
* I read the first few chapters of Pharo by Example as an introduction to Pharo. * The browser, debugger and basic inspectors are all familiar enough that I was able to work with them without any issues. * I'm glad that being able to run headless mode is easy, as I'd like to use Pharo for scripting. * The addition of Montacello / Metacello / Gofer and SUnit are the biggest improvements I've noticed so far. I wish I had these 20 years ago. * I've only played with the MessageFlow Browser a little, but I think it will be one of my go-to tools. * I'm still getting used to the idea of the entire ST environment being in a single OS window, but at the moment I think I prefer VW's approach where each ST window is a OS window, as it makes it easier to work with other applications, e.g. if I want to look at an email or web page while working within ST.
I only have one suggested improvement so far (assuming it doesn't already exist and I just haven't found it yet)... When searching for packages on SqueakSource / SmalltalkHub etc. it isn't clear to me how much confidence I can have in any given package, which is really useful if there are multiple packages providing similar functionality.
The Arch Linux model seems pretty good to me. Official packages are in the core or extra repositories, which matches what is included in the Pharo image. The next level is a community repository, which contains packages maintained by Trusted Users. General users can be confident that these packages will be kept up to date. The last level is the User Repository (AUR), which anyone can contribute to. The AUR includes a comment section and vote count, and general users can add or remove their vote. I'd like to see something like this too.
us too first you have some pharo extras packages second favor package with tests third we have been working on quality rules and quality rule false positive management so you can run the tests and run the rules now we will start to work on package validation to produce a kind of "validated" distribution of pharo packages. Stef
Combining several replies in to one... On Tue, Apr 12, 2016 at 08:37:30PM +0200, Stephan Eggermont wrote:
On 12-04-16 19:51, Alistair Grant wrote:
I only have one suggested improvement so far (assuming it doesn't already exist and I just haven't found it yet)... When searching for packages on SqueakSource / SmalltalkHub etc. it isn't clear to me how much confidence I can have in any given package, which is really useful if there are multiple packages providing similar functionality.
One of our community tools for that is a continuous integration server: http://ci.inria.fr/pharo-contribution. There several of these configurations are build and tested, often against several Pharo versions. Several Pharo users are also already using TravisCI and github for that.
Stephan
On Tue, Apr 12, 2016 at 09:28:07PM +0200, stepharo wrote:
On 12-04-16 19:51, Alistair Grant wrote:
The Arch Linux model seems pretty good to me. Official packages are in the core or extra repositories, which matches what is included in the Pharo image. The next level is a community repository, which contains packages maintained by Trusted Users. General users can be confident that these packages will be kept up to date. The last level is the User Repository (AUR), which anyone can contribute to. The AUR includes a comment section and vote count, and general users can add or remove their vote. You get a bit of that in the catalog browser.
On Wed, Apr 13, 2016 at 08:06:26AM +0200, stepharo wrote:
Le 13/4/16 06:48, John Pfersich a écrit :
On Apr 12, 2016, at 10:51, Alistair Grant <akgrant0710@gmail.com> wrote:
The Arch Linux model seems pretty good to me. Official packages are in the core or extra repositories, which matches what is included in the Pharo image. The next level is a community repository, which contains packages maintained by Trusted Users. General users can be confident that these packages will be kept up to date. The last level is the User Repository (AUR), which anyone can contribute to. The AUR includes a comment section and vote count, and general users can add or remove their vote. I'd like to see something like this too.
us too first you have some pharo extras packages second favor package with tests third we have been working on quality rules and quality rule false positive management so you can run the tests and run the rules
now we will start to work on package validation to produce a kind of "validated" distribution of pharo packages.
Thanks to everyone for their replies and welcome messages. It looks like I need to learn more about: * The catalogue browser * Montacello / git integration * Finding the automated tests for a given package Between that and the improvements mentioned above we seem to be in pretty good shape. I still like the idea of a vote button as it gives a rough indication of usefulness / popularity. Of course I should actually contribute some code instead of just pontificating... Thanks! Alistair
On Wed, Apr 13, 2016 at 1:51 AM, Alistair Grant <akgrant0710@gmail.com> wrote:
* I'm glad that being able to run headless mode is easy, as I'd like to use Pharo for scripting.
I'm not sure of its status, but Coral was some experiments along this line... https://www.youtube.com/watch?v=HLb_rMcNN6k
* I'm still getting used to the idea of the entire ST environment being in a single OS window, but at the moment I think I prefer VW's approach where each ST window is a OS window, as it makes it easier to work with other applications, e.g. if I want to look at an email or web page while working within ST.
This will become more possible over time as some native window management is being moved out of VM into the Image. cheers -ben
Heh. The last days I've had a look at Coral⦠my current goal is to remove the dependency to PetitParser from the argument parser, and to re-integrate that with the commandline handler system of the image. But that's only one part⦠On 14 April 2016 at 01:43, Ben Coman <btc@openinworld.com> wrote:
On Wed, Apr 13, 2016 at 1:51 AM, Alistair Grant <akgrant0710@gmail.com> wrote:
* I'm glad that being able to run headless mode is easy, as I'd like to use Pharo for scripting.
I'm not sure of its status, but Coral was some experiments along this line... https://www.youtube.com/watch?v=HLb_rMcNN6k
* I'm still getting used to the idea of the entire ST environment being in a single OS window, but at the moment I think I prefer VW's approach where each ST window is a OS window, as it makes it easier to work with other applications, e.g. if I want to look at an email or web page while working within ST.
This will become more possible over time as some native window management is being moved out of VM into the Image.
cheers -ben
Le 14/4/16 01:52, Damien Pollet a écrit :
Heh. The last days I've had a look at Coral⦠my current goal is to remove the dependency to PetitParser from the argument parser, and to re-integrate that with the commandline handler system of the image. But that's only one partâ¦
Yes it would be really nice.
On 14 April 2016 at 01:43, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:
On Wed, Apr 13, 2016 at 1:51 AM, Alistair Grant <akgrant0710@gmail.com <mailto:akgrant0710@gmail.com>> wrote:
> * I'm glad that being able to run headless mode is easy, as I'd like to > use Pharo for scripting.
I'm not sure of its status, but Coral was some experiments along this line... https://www.youtube.com/watch?v=HLb_rMcNN6k
> * I'm still getting used to the idea of the entire ST environment being > in a single OS window, but at the moment I think I prefer VW's > approach where each ST window is a OS window, as it makes it easier to > work with other applications, e.g. if I want to look at an email or > web page while working within ST.
This will become more possible over time as some native window management is being moved out of VM into the Image.
cheers -ben
Welcome! Stef Le 11/4/16 20:40, Alistair Grant a écrit :
Hi Serge,
On Mon, Apr 11, 2016 at 09:46:02AM +0200, Serge Stinckwich wrote:
On Mon, Apr 11, 2016 at 8:57 AM, Alistair Grant <akgrant0710@gmail.com> wrote:
Also my first week with Pharo, and first week with Smalltalk in over 20 years. Congrats ! Tell us what is your experience until now ;-) I was the technical lead of a team that programmed with VisualWorks 2.5 for several years in the 90's, porting it to VMS (VAX and Aplha) and writing a real-time graphical interface for monitoring and controlling the water distribution in one of the capital cities in Australia (Brisbane).
The UI allowed users to build a library of widgets from basic shapes, e.g. valves, pumps, reservoirs, etc. They could then be built up to schematics and attached to a real-time database, receiving events whenever a value changed. E.g. valves would change shape or colour depending on whether they were open or closed, alarms would flash, a pump would show its flow rate, etc.
We tested it receiving up to 1200 events per second (this was in the days when a 100MHz RISC processor was the best available (from memory)). All the graphics, event management and query optimisation were in Smalltalk, the database query execution and event delivery was in C (the database was in-memory and didn't support any query language, that all had to be done by the client).
I left the company a year or so later. I heard that it was replaced some years after I left, but I'm not sure when that happened.
Cheers, Alistair
Alistair Grant wrote
Also my first week with Pharo, and first week with Smalltalk in over 20 years.
How exciting! Three oldtime Smalltalkers discovering Pharo in a week... and, letting us know :) Welcome. ----- Cheers, Sean -- View this message in context: http://forum.world.st/About-Box-tp4889296p4889383.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
participants (11)
-
Alistair Grant -
Ben Coman -
Bruce Peaslee -
Cyril Ferlicot -
Damien Pollet -
John Pfersich -
Robert J Rothwell -
Sean P. DeNigris -
Serge Stinckwich -
Stephan Eggermont -
stepharo