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

Re: [Pharo-users] Thanks for Pharo

by Jimmie Houchin

On 10/18/2015 11:51 AM, Ben Coman wrote: > Thanks very much for your thoughts Jimmie. Day to day, its easy to > take for granted what we have. > > On Sat, Oct 17, 2015 at 6:14 AM, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >> Sometimes conversations revolve around perceived deficiencies in Pharo. What >> Pharo is missing. Or what Pharo doesn't do as well as my previous language, >> my favorite language, my other language, etc... These conversations are >> necessary to understand where Pharo is and to provide understanding on where >> Pharo needs some work. >> >> However, not enough gets said sometimes for all the goodness Pharo already >> provides and thanks to all of those who have contributed over the years to >> Smalltalk/Pharo. >> >> I know sometimes we get stuck in the minutiae and lose the big picture. >> >> I just want to say thanks to all that have contributed to Pharo in big and >> small way. Thank you. >> >> A special thanks to Stef, Marcus and company who have been working hard on >> this all the way back when it was still Squeak. Who had a vision for a >> clean, empowering, business ready, vision fulfilling Smalltalk inspired tool >> we call Pharo. Thanks. > > Stef's "Pharo Vision" [1] document was a big part of what drew me to > Pharo. Not necessarily what was in it, but more just that there was > such a vision. > > [1] https://gforge.inria.fr/frs/download.php/30434/PharoVision.pdf Absolutely. This is a very important thing. A vision that moves the community and project forward is exceptionally important. To me a project without a vision statement or at least a roadmap is direction less and quite possible dying. Show me some life before I invest my time. >> And a thanks to Eliot and all who contribute on the VM side of things. >> Enabling us to have a nicely performing and stable vm to run the Pharo >> image. > ... >> I want to take time to appreciate some things in Pharo that make us >> appreciate having a tool like Pharo and which distinguishes itself from >> other languages and environments. I think these things either distinguish >> themselves either in the relative uniqueness or in quality of their >> implementation. They are not necessarily distinguishing from other >> Smalltalks but from other non-Smalltalk languages. >> >> Superior persistent live object environment. >> This is the game changer and affects and enables all other benefits. >> >> IDE, debugging and refactoring, all live, all the time. > The debugger (within a live environment) does it for me. Its what > make using Pharo fun. Exactly. You hit a bug, execution stops and you can start exploring the problem where the problem is. With live tools and the executing code available and inspectable. No dead stack trace saying go to another tool and look at line X and you might find your problem. Or it might be in a different file or ... And if that doesn't do it for you. Execute your program in another tool in order to debug and explore the executing code. To many separate, isolated and distinct processes and tools. >> Because of the truly persistent live environment, there is no concept of >> shutdown, restart. We only know hibernate and resume. This is to use OS >> terms. For me this is an amazing boost to productivity. I can at any time >> save my image. Even close my saved image and resume exactly where I stopped. >> At any time, on any supported OS, on any machine. Powerful. >> >> There truly is no edit, compile, run cycle similar to other languages, even >> dynamically typed languages with REPLs. > I view that we do have an edit/compile/run loop, its just really tight loop! > I recently had a passing thought we could market Pharo as REPL+. Here is what I was saying. In Pharo there is not separate tool for editing, then a different tool for compiling and running. Yes, there are distinct phases of process requiring editing, compiling and running in Pharo, But they all exist in a single process. In Pharo I can have multiple Workspaces/Playgrounds and multiple Code Browsers, Inspectors, Debuggers and Testing Tools all open at the same time. I can flow from one to another and they all be viewing, editing, executing, inspecting the same objects, instances. Where else can we have multiple editors, compilers, repls, and whatever tools, all operating on the same objects and instances? As wonderful as Jupyter may be, can it have multiple windows with a view into the same repl instance? Maybe? I don't know. But now throw into that picture your favorite editor or IDE. Can it have multiple files open and seamlessly edit the code running in that single repl instance? The same instance as is in the Jupyter. Even if you get all of those tools communicating via sockets or whatever to a single Python/Julia/??? instance. It is still a very poor comparison to the workflow in any Smalltalk. Then you get to the end of your workday. There is no save menu to persist the state of all of those tools and repl all working together. In Pharo, just one tool, Pharo. Everything exists inside Pharo. Wonderful. > In addition: > > The ability for the system (and community culture) to evolve a live > running system. This is ideal for applications like control systems > for industrial plants running 365x24. For example an alumina refinery > where kilometers of pipes carry fluids at 800 degree, which would > solidify in the pipes if there was an 8hr power outage, which could > essentially close the plant down permanently so you'd have to walk > away from a billion dollar investment. Another example might be > space faring robots. Pharo is not right now at the point where you > might trust it for such an extreme purpose, but the potential is > there. Absolutely. The already existent, persistent live environment is a powerful thing. The fact that we have code in Pharo that is decades old and has never been in a state disconnected from a live, running environment is amazing. Where else do we find that? What other software, programming language has a vision to provide such facility? Most everything else is designed to build something which you release and run. Release from your edit, build, compile to a run environment. Smalltalk and therefore Pharo is ontological and not merely a tool to build something external to itself. This is a huge difference. https://en.wikipedia.org/wiki/Ontology One of the things I find inspiring in the talks by Richard Hipp about SQLite is the level of the quality of the code in SQLite. That its file format is stable and guaranteed. That its codebase has complete test coverage. Coverage sufficient for its use in avionics systems. http://sqlite.org/testing.html I know Pharo is not going to be used in such a system. But it would be interesting if we can have decent coverage on the core or kernel as the everything get reduced to a buildable system. Then test coverage can more easily be applied on a system which is smaller and understandable. I have no concept of how you do the vm. It would be nice to get to a point some day that certain quality standards can be insured to a certain point. Not necessarily to the extent that SQLite does. But to a nice level. But SQLite has money, supporters, paying for SQLite to have that level of coverage. That also makes a big difference. Thanks for engaging in the conversation. Jimmie > > cheers -ben >

Oct. 19, 2015

Re: [Pharo-users] CiteZen and Pharo 5 / Pharo4 tests

by stepharo

Fixed and I pushed two new configurations of in MetaRepo 40 and 50 Le 18/10/15 17:33, Stephan Eggermont a Ã©crit : > On 18-10-15 12:31, Stephan Eggermont wrote: >> I've committed a version to the MetaRepoForPharo50 as I >> couldn't write in the repo. In Pharo 5 it doesn't load. >> I changed the build to use the MetaRepo version and build both 4 and 5 >> versions. > > In Citezen-Reborn-StephaneDucasse.36 there is the method > CZSingleAuthorDocBuilder class>>#latex > that doesn't compile in Pharo 5 > > 'latex > "self latex" > > | builder | > builder := self new > fileNamed: ''rmod.bib''; > toLatex; > french; > fieldOrder: #(#author > #title > #journal > #booktitle > #volume > #pages > #publisher > #year > # school > #impactfactor > #misc); "removed doi and url since they may contain _ > and the generator does not handle that well for the moment." > setFilteringOn; > yourself. > builder generateLatexFile. > ' > > because of the space between # and school. > > Getting from the Syntax Error: Expecting a literal type to the > compilation context is 19 levels deep on the stack. I think it would > be useful to present more information than just the error message and > the source when loading & compiling a package. > > BibPhraseLibrary twice uses #allMethodsInCategory: that should be > replaced by allSelectorsInProtocol: (deprecated in Pharo 3) in > Citezen-Rendering. > > In baseline1.7 the dependencies on Seaside/Grease/Pier/Magritte > versions probably need updates. Magritte2 and Pier2 have never been > tried on Pharo5 AFAIK. Smacc has moved to github. > > Stephan > > >

Oct. 19, 2015

Re: [Pharo-users] CiteZen and Pharo 5 / Pharo4 tests

by stepharo

Oops I will fix that. Le 18/10/15 17:33, Stephan Eggermont a Ã©crit : > On 18-10-15 12:31, Stephan Eggermont wrote: >> I've committed a version to the MetaRepoForPharo50 as I >> couldn't write in the repo. In Pharo 5 it doesn't load. >> I changed the build to use the MetaRepo version and build both 4 and 5 >> versions. > > In Citezen-Reborn-StephaneDucasse.36 there is the method > CZSingleAuthorDocBuilder class>>#latex > that doesn't compile in Pharo 5 > > 'latex > "self latex" > > | builder | > builder := self new > fileNamed: ''rmod.bib''; > toLatex; > french; > fieldOrder: #(#author > #title > #journal > #booktitle > #volume > #pages > #publisher > #year > # school > #impactfactor > #misc); "removed doi and url since they may contain _ > and the generator does not handle that well for the moment." > setFilteringOn; > yourself. > builder generateLatexFile. > ' > > because of the space between # and school. > > Getting from the Syntax Error: Expecting a literal type to the > compilation context is 19 levels deep on the stack. I think it would > be useful to present more information than just the error message and > the source when loading & compiling a package. > > BibPhraseLibrary twice uses #allMethodsInCategory: that should be > replaced by allSelectorsInProtocol: (deprecated in Pharo 3) in > Citezen-Rendering. > > In baseline1.7 the dependencies on Seaside/Grease/Pier/Magritte > versions probably need updates. Magritte2 and Pier2 have never been > tried on Pharo5 AFAIK. Smacc has moved to github. > > Stephan > > >

Oct. 19, 2015

Re: [Pharo-users] Thanks for Pharo

by stepharo

Sorry not to react I got sick and I'm still quite fussy. Thanks for your mail. Stef Le 17/10/15 00:14, Jimmie Houchin a Ã©crit : > Sometimes conversations revolve around perceived deficiencies in > Pharo. What Pharo is missing. Or what Pharo doesn't do as well as my > previous language, my favorite language, my other language, etc... > These conversations are necessary to understand where Pharo is and to > provide understanding on where Pharo needs some work. > > However, not enough gets said sometimes for all the goodness Pharo > already provides and thanks to all of those who have contributed over > the years to Smalltalk/Pharo. > > I know sometimes we get stuck in the minutiae and lose the big picture. > > I just want to say thanks to all that have contributed to Pharo in big > and small way. Thank you. > > A special thanks to Stef, Marcus and company who have been working > hard on this all the way back when it was still Squeak. Who had a > vision for a clean, empowering, business ready, vision fulfilling > Smalltalk inspired tool we call Pharo. Thanks. > > And a thanks to Eliot and all who contribute on the VM side of things. > Enabling us to have a nicely performing and stable vm to run the Pharo > image. > > My apologies for not naming everyone who deserves thanks. I intend no > offense to anyone not named, but also deserving. Your names are > included in all the contributor documentation. Thanks. > > And while I am being thankful, which is a good habit for all of us to > be in. Being thankful not only improves the spirits of those being > thanked. But those of us who are grateful are the biggest beneficiaries. > > I want to take time to appreciate some things in Pharo that make us > appreciate having a tool like Pharo and which distinguishes itself > from other languages and environments. I think these things either > distinguish themselves either in the relative uniqueness or in quality > of their implementation. They are not necessarily distinguishing from > other Smalltalks but from other non-Smalltalk languages. > > > > Superior persistent live object environment. > This is the game changer and affects and enables all other benefits. > """I'm not complaining. I know that there is a good chance that we break > the system when improving it. I have no problem with that and I prefer > a living system with some bugs > for a while than a dead system with no bug""" Stef - Sept. 7, 2015 > > > IDE, debugging and refactoring, all live, all the time. > > > Because of the truly persistent live environment, there is no concept > of shutdown, restart. We only know hibernate and resume. This is to > use OS terms. For me this is an amazing boost to productivity. I can > at any time save my image. Even close my saved image and resume > exactly where I stopped. At any time, on any supported OS, on any > machine. Powerful. > > There truly is no edit, compile, run cycle similar to other languages, > even dynamically typed languages with REPLs. > If I am not in Pharo, even if that language has an amazing notebook or > repl available. It is nothing like coding in the live environment. The > separation of editor and the compiler and/or application or VM makes > development not as smooth and fluid. Even if I can enter and execute > code in a notebook or repl to explore and learn in a version of a live > environment. I still at some point have to leave my editing > environment and write, edit and save my source code. And yes there are > languages, editors, IDEs and tools that attempt to close the gap. But > no, there still is a significant gap. The edited source code is the > only thing that persists. Everything that gets executed in the repl or > notebook is transient and will go away. > > MIT, equivalent or better licensed ecosystem. > > For me these are game changers. They set a standard by which I view > any other programming experience. Thusly all other programming > experience falls far short. > > Whenever I (we) experience a present weakness in Pharo. Remember the > above. > Not only does Pharo have these distinguishing factors. I do not know > of any language or environment which even has a culture or worldview > of programming which seeks to bring these features to their favored > language or tools. > > Every time I have to restart my computer I think, Smalltalk solved > this decades ago. Ugh!!! > Where is my Pharo machine. :) > > If you have any Pharo distinctives that you appreciate and would like > to share. Reply and let us know. > What I mean by distinctive is something that Pharo (or Smalltalk) has > that is either not in other languages or is in general significantly > inferior. Especially those that other languages have no vision to ever > have. It just isn't a part of who they are. > > If we keep these things before us as we work through the tedious work > of cleaning the image, repairing fail attempts at various things. Or > anything that may be a frustration for the moment, but is temporary. > Remember what we gain and are blessed with having, that we would lose > any where else. Or at a minimum have a far inferior substitute. And > look forward to what we will have as these things become complete. The > future is ours. Let's enjoy the journey. > > Just some thoughts in my head I wanted to let out. > This is reminder to me. If any of you are blessed and inspired, that > is a plus. > > Thanks and Shalom. > > Jimmie > > > > >

Oct. 19, 2015

Re: [Pharo-users] loading GToolkit in Pharo 3.0 no longer works

by Andrei Chis

How are you loading it? What errors do you get? The moose 5 job from the CI that loads moose on top of pharo 3 still works. https://ci.inria.fr/moose/job/moose-5.0/ Cheers, Andrei On Sun, Oct 18, 2015 at 8:40 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > It used to but the configurations have been really messed up. > > e.g. I get "Bricks" mentions... > > Phil >

Oct. 18, 2015

Re: [Pharo-users] Error: Unable to resolve external type: sqlite_int64 (It was Re: Live interaction with SQLite data from Pharo)

by Offray Vladimir Luna CÃ¡rdenas

Hi again, Solved! Torsten advice was: ~~~ Change apiBindInteger: aStatement atColumn: aColumn with: anInteger to use an integer in the NB call 1:41 <https://pharoproject.slack.com/archives/general/p1445193666002305> apiBindInteger: aStatement atColumn: aColumn with: anInteger "int sqlite3_bind_int64(sqlite3_stmt*, int, sqlite_int64)" <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> ^ self nbCall: #(int sqlite3_bind_int64 (sqlite3_stmt aStatement, int aColumn, int anInteger)) module: self library ~~~ And now works. Thanks a lot!!! Now I have another problem. If I ran http://ws.stfx.eu/1VPMHQXNL35N the first insert command generates a new row in the database but the second one doesn't, as is shown by querying the database from sqlite3 command client. What I'm missing? Cheers, Offray On 18/10/15 13:22, Offray Vladimir Luna CÃ¡rdenas wrote: > Hi, > > I'm trying my queries in a more static form. My idea is to get proper > insertion of Smalltalk object values on a SQLite database, but when I > try: > > ~~~ > > db execute: 'INSERT INTO BLOGPOSTS values (?, "Hola mundo!");' > with: #(2) > > ~~~ > > I get: > > error message: "Error: Unable to resolve external type: sqlite_int64" > > So seems that the number is trying to talk with the 64 bits of Sqlite > instead of the 32 bits one which is in the same place that the image. > > Any way to solve this? > > Thanks, > > Offray > > > On 18/10/15 10:48, Offray Vladimir Luna CÃ¡rdenas wrote: >> Hi, >> >> I have followed the short tutorials[1][2] on SQLite and Pharo and my >> connection is working properly. But I miss some liveliness on how >> interact with data base, particularly after seeing the video from >> Doru at [3], where near to min 38 he shows a connection with a >> Posgresql data base which after ran on the playground results in a >> nice vire with a tab for putting the SQL code and another for >> inspecting the results in a table format, even for adding data live. >> Is this functionality only available on Postgres or can also be >> enabled on a connection for SQLite and if yes, how can it be done? >> >> [1] >> http://lists.gforge.inria.fr/pipermail/pharo-project/2010-October/033564.ht… >> [2] http://smalltalkhub.com/#!/~PharoExtras/NBSQLite3 >> [3] https://vimeo.com/97315968 >> >> Thanks, >> >> Offray >> >> > > >

Oct. 18, 2015

Pharo and Fossil

by Hilaire

Hello, Following the recent post on SQLite, I came to read about Fossil[1]. Are any of you using Fossil for Pharo project? If so what is your required set up, script, etc.? Thanks Hilaire [1] http://www.fossil-scm.org -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu

Oct. 18, 2015

loading GToolkit in Pharo 3.0 no longer works

by phil＠highoctane.be

It used to but the configurations have been really messed up. e.g. I get "Bricks" mentions... Phil

Oct. 18, 2015

Error: Unable to resolve external type: sqlite_int64 (It was Re: Live interaction with SQLite data from Pharo)

by Offray Vladimir Luna CÃ¡rdenas

Hi, I'm trying my queries in a more static form. My idea is to get proper insertion of Smalltalk object values on a SQLite database, but when I try: ~~~ db execute: 'INSERT INTO BLOGPOSTS values (?, "Hola mundo!");' with: #(2) ~~~ I get: error message: "Error: Unable to resolve external type: sqlite_int64" So seems that the number is trying to talk with the 64 bits of Sqlite instead of the 32 bits one which is in the same place that the image. Any way to solve this? Thanks, Offray On 18/10/15 10:48, Offray Vladimir Luna CÃ¡rdenas wrote: > Hi, > > I have followed the short tutorials[1][2] on SQLite and Pharo and my > connection is working properly. But I miss some liveliness on how > interact with data base, particularly after seeing the video from Doru > at [3], where near to min 38 he shows a connection with a Posgresql > data base which after ran on the playground results in a nice vire > with a tab for putting the SQL code and another for inspecting the > results in a table format, even for adding data live. Is this > functionality only available on Postgres or can also be enabled on a > connection for SQLite and if yes, how can it be done? > > [1] > http://lists.gforge.inria.fr/pipermail/pharo-project/2010-October/033564.ht… > [2] http://smalltalkhub.com/#!/~PharoExtras/NBSQLite3 > [3] https://vimeo.com/97315968 > > Thanks, > > Offray > >

Oct. 18, 2015

Re: [Pharo-users] Thanks for Pharo

by Ben Coman

Thanks very much for your thoughts Jimmie. Day to day, its easy to take for granted what we have. On Sat, Oct 17, 2015 at 6:14 AM, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > Sometimes conversations revolve around perceived deficiencies in Pharo. What > Pharo is missing. Or what Pharo doesn't do as well as my previous language, > my favorite language, my other language, etc... These conversations are > necessary to understand where Pharo is and to provide understanding on where > Pharo needs some work. > > However, not enough gets said sometimes for all the goodness Pharo already > provides and thanks to all of those who have contributed over the years to > Smalltalk/Pharo. > > I know sometimes we get stuck in the minutiae and lose the big picture. > > I just want to say thanks to all that have contributed to Pharo in big and > small way. Thank you. > > A special thanks to Stef, Marcus and company who have been working hard on > this all the way back when it was still Squeak. Who had a vision for a > clean, empowering, business ready, vision fulfilling Smalltalk inspired tool > we call Pharo. Thanks. Stef's "Pharo Vision" [1] document was a big part of what drew me to Pharo. Not necessarily what was in it, but more just that there was such a vision. [1] https://gforge.inria.fr/frs/download.php/30434/PharoVision.pdf > And a thanks to Eliot and all who contribute on the VM side of things. > Enabling us to have a nicely performing and stable vm to run the Pharo > image. > ... > I want to take time to appreciate some things in Pharo that make us > appreciate having a tool like Pharo and which distinguishes itself from > other languages and environments. I think these things either distinguish > themselves either in the relative uniqueness or in quality of their > implementation. They are not necessarily distinguishing from other > Smalltalks but from other non-Smalltalk languages. > > > > Superior persistent live object environment. > This is the game changer and affects and enables all other benefits. > > IDE, debugging and refactoring, all live, all the time. The debugger (within a live environment) does it for me. Its what make using Pharo fun. > Because of the truly persistent live environment, there is no concept of > shutdown, restart. We only know hibernate and resume. This is to use OS > terms. For me this is an amazing boost to productivity. I can at any time > save my image. Even close my saved image and resume exactly where I stopped. > At any time, on any supported OS, on any machine. Powerful. > > There truly is no edit, compile, run cycle similar to other languages, even > dynamically typed languages with REPLs. I view that we do have an edit/compile/run loop, its just really tight loop! I recently had a passing thought we could market Pharo as REPL+. In addition: The ability for the system (and community culture) to evolve a live running system. This is ideal for applications like control systems for industrial plants running 365x24. For example an alumina refinery where kilometers of pipes carry fluids at 800 degree, which would solidify in the pipes if there was an 8hr power outage, which could essentially close the plant down permanently so you'd have to walk away from a billion dollar investment. Another example might be space faring robots. Pharo is not right now at the point where you might trust it for such an extreme purpose, but the potential is there. cheers -ben

Oct. 18, 2015