December 2015 - Pharo-users

Re: [Pharo-users] Stop Thinking in Terms of Files

by Thierry Goubier

Le 07/12/2015 02:50, Martin BÃ¤hr a Ã©crit : > Excerpts from Sven Van Caekenberghe's message of 2015-12-06 19:39:51 +0100: >> There are a lot of questions in there, too much to answer. > > i am interested in the versioning of code and objects. > the poster makes a good point there. The traditional, full approach, would have been to use an object oriented database like GemStone. Anything that can version objects can version Smalltalk code. > what if i am on a non-networked machine, running pharoNOS or even squeakNOS, > how would i keep old versions of my code/objects? is there any in-image > solution for that? The .changes provides that in a limited form. It would be easy to do better in memory, if needed. > greetings, martin. Regards, Thierry

Dec. 7, 2015

Re: [Pharo-users] [squeak-dev] Re: evolutions of squeakelib & crypto (Reed Solomon)

by Robert Withers

Thanks, Chris! I'll tuck this away until I get back to my presentation layer. On 12/06/2015 02:03 PM, Chris Muller wrote: > On Fri, Dec 4, 2015 at 5:15 AM, Robert Withers > <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> wrote: > > I just realized that the squeak version uses ReferenceStream while > the Pharo version uses Fuel, so the binary serializations are > different and they won't speak to each other. Any chance that Fuel > is ported to Squeak? > > > Installer new merge: #fuel > > >

Dec. 7, 2015

Re: [Pharo-users] Stop Thinking in Terms of Files

by Martin BÃ¤hr

Excerpts from Sven Van Caekenberghe's message of 2015-12-06 19:39:51 +0100: > There are a lot of questions in there, too much to answer. i am interested in the versioning of code and objects. the poster makes a good point there. what if i am on a non-networked machine, running pharoNOS or even squeakNOS, how would i keep old versions of my code/objects? is there any in-image solution for that? greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

Dec. 7, 2015

Re: [Pharo-users] Stop Thinking in Terms of Files

by horrido

And for the record, a number of long-time Smalltalkers have expressed their appreciation for the work I've done. One of them (a 25-year Smalltalk veteran!!!) said to me: "You may think the job was thankless, but I think you did a great job." I really, truly appreciate his accolade. Hey, I get it. Not everybody agrees with my marketing approach. *And not every Smalltalker wants Smalltalk to become popular.* I expect these folks to be in the minority. It is sad and unfortunate that the Smalltalk community is divided in this manner. kilon.alios wrote > *Look man you do more harm with these articles than you do good. This > Smalltalk hype is the worst of its kind and completely misses the point of > why Smalltalk is great. * -- View this message in context: http://forum.world.st/Stop-Thinking-in-Terms-of-Files-tp4865614p4865648.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 6, 2015

Re: [Pharo-users] Stop Thinking in Terms of Files

by horrido

I didn't say I cannot answer the questions; I said I may not answer them /optimally/. After all, *I haven't used Smalltalk in a long while*, and I was never an expert to begin with. I'm certainly not up with the latest developments in Pharo. (For example, I didn't know that Pharo no longer has filein/fileout.) I'd rather not give a weak response. Hence, I appealed to you guys. You live and breathe Smalltalk; I don't. I posted in amber-lang because I know many Pharoers are there, too, and I use Amber. The Pharo forum is less inviting for me, I find. This thread is a fine example. kilon.alios wrote > *And on top of that there are people there asking you the easiest > questions > and you cannot even answer them while at the same time you proclaim the > end > of File's "Stone age". * > > *And on top of that you post this in amber-lang which is not even relevant > in any way with your article (since its not image based) just to get more > attention. * -- View this message in context: http://forum.world.st/Stop-Thinking-in-Terms-of-Files-tp4865614p4865643.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 6, 2015

Re: [Pharo-users] Stop Thinking in Terms of Files

by horrido

"An image is essentially a self-contained operating system that manages all the code for you, thanks to an easy-to-use IDE." I'm not trying to be pedantic. I'm using general parlance to convey an idea, and the idea is essentially correct. And I'm hardly alone. GemTalk's own "Pharo, the collaborActive Book" defines image in much the same way: "A Smalltalk Image is your entire system. The Image includes all the tools required to interact, customize and add functionality to your system, so Smalltalkâs IDE is a very Integrated Development Environment." Let's not conflate /implementation/ with the Smalltalk UI experience. Of course, under the hood, Smalltalk is implemented using files. Duh! Today, Smalltalk is hosted on Windows or Mac OS or Linux or whatever other OS. But the original idea behind Smalltalk was that it would be a self-contained operating system; no host required. Think back to the Xerox PARC days: how did they host Smalltalk? Remember the Xerox Alto <https://www.wikiwand.com/en/Xerox_Alto> ? The reality is that the entire world is deeply entrenched on using files, much the same way the entire world is entrenched on using QWERTY keyboards and automobile steering wheels. Smalltalk has to live in this world, /so it makes accommodations/ for filein/fileout, Git, etc. Amber for the web has to live with HTML, CSS, and JS files. However, this does not alter the basic premise of my article. Smalltalk programming is a file-free abstraction. In order to enjoy this environment, you should mentally unfetter yourself from the traditional methodology of using file-based tools like Emacs, IntelliJ, and so on. *This is one of the main things holding back developers.* kilon.alios wrote > " > > *Files belong in the Stone Age"* > > *No they do not !* > > "Smalltalk is an *image-based* programming language." > > An image IS a file !!! > > "An image is essentially a self-contained operating system that manages > all > the code for you, thanks to > > *an easy-to-use IDE"* > > > *no its not!!! the vm is the virtual OS , the image is the OS libraries. > The VM also is a binary file separate from image and comes with a lot more > files , plugins and external libraries. * > > > *Look man you do more harm with these articles than you do good. This > Smalltalk hype is the worst of its kind and completely misses the point of > why Smalltalk is great. * > > > *It would even make zero diffirence if we were to break the image file > down > to much smaller files, it would still be a live coding enviroment. > Actually > you dont even need those files to be even binary , text source code files > can still store live state and be all about objects. * -- View this message in context: http://forum.world.st/Stop-Thinking-in-Terms-of-Files-tp4865614p4865642.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 6, 2015

Re: [Pharo-users] Stop Thinking in Terms of Files

by Dimitris Chloupis

" *Files belong in the Stone Age"* *No they do not !* "Smalltalk is an *image-based* programming language." An image IS a file !!! "An image is essentially a self-contained operating system that manages all the code for you, thanks to *an easy-to-use IDE"* *no its not!!! the vm is the virtual OS , the image is the OS libraries. The VM also is a binary file separate from image and comes with a lot more files , plugins and external libraries. * *Look man you do more harm with these articles than you do good. This Smalltalk hype is the worst of its kind and completely misses the point of why Smalltalk is great. * *It would even make zero diffirence if we were to break the image file down to much smaller files, it would still be a live coding enviroment. Actually you dont even need those files to be even binary , text source code files can still store live state and be all about objects. * *And on top of that there are people there asking you the easiest questions and you cannot even answer them while at the same time you proclaim the end of File's "Stone age". * *And on top of that you post this in amber-lang which is not even relevant in any way with your article (since its not image based) just to get more attention. * On Sun, Dec 6, 2015 at 8:40 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > There are a lot of questions in there, too much to answer. > > The basic answer is that everything is modelled as objects, even the > objects themselves. There is a complete meta model of what could be > considered code and even the execution of code. Furthermore, even > versioning is modelled nicely too. Of course, Pharo interfaces with the > outside world, it can read and write files, it can do networking. The > object world and its code can, in various ways, be mapped to concepts of > this world. For example, https://github.com/pharo-project/pharo-core > contains (a copy, one representation) of all code in Pharo. There is also > the option to save the whole object world to a single snapshot file, called > an image. Running on servers, containers, embedded devices is all possible, > in multiple ways, with or without a (G)UI. At that point Pharo consists of > a couple of files, most notably the image file. > > HTH, > > Sven > > > On 06 Dec 2015, at 17:58, horrido <horrido.hobbies(a)gmail.com> wrote: > > > > I submitted an article at Reddit called "Stop Thinking in Terms of > Files." > > Some guy with the handle "audioen" wrote the following comment: > > > > We have heard that smalltalk appears to use model similar to a LISP > machine > > of yore in that the programming environment = the OS = the runtime > > environment. Once you define a function, it simply exists without being > > written to a file or compiled into some process that runs it. You can > just > > call it, or undefine it and it ceases to be. From this point of view, it > is > > probably perfectly valid to say that it has no files, because it doesn't > > need them. > > > > On the other hand, let's assume that your smalltalk image got a little > bit > > corrupted so that some packages/functions/whatever are now missing or not > > functioning. Or, let's say that you accidentally undefined a function and > > that was a mistake and now you really want to get it back. How would you > do > > that? The file-based answer is that you hopefully had backups of the > files > > that held definition of that function. What passes for a backup in > smalltalk > > land? > > > > And how do you deal with version control? How do you recover from > mistakes? > > If you wanted to share your crap to someone else collaboratively through > > e.g. github, how would you do that? You'd have to export your functions > into > > individual files, probably, and packages as directories into git. Someone > > would check them out, eval them, make changes, and commit updated > functions. > > How does this kind of process look like, in a non-file paradigm, if it is > > done at all? (Does smalltalk VM even support networking?) > > > > In general how do you even dump the state of the VM in some way that you > can > > show someone what exactly your project is made of, in textual form? It's > not > > very nice to dump an entire image and tell them to just run that. I bet > the > > image is much larger and contains historical stuff that you no longer > care > > about. What if you really just wanted to publish a recipe that can > construct > > something equivalent of that particular image? What does "docker" for > > smalltalk look like? > > > > If you tell us files suck, tell us also how you solve the same problems > that > > we solve through files. Especially that collaborative programming through > > github use case interests me a little. > > ----- > > > > I must confess, I'm not fully qualified to answer this comment, /at > least, > > not optimally/. Perhaps some of you can go to the Reddit link > > < > https://www.reddit.com/r/programming/comments/3vjlta/stop_thinking_in_terms… > > > > and respond? Thanks. > > > > > > > > -- > > View this message in context: > http://forum.world.st/Stop-Thinking-in-Terms-of-Files-tp4865614.html > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > >

Dec. 6, 2015

Re: [Pharo-users] Stop Thinking in Terms of Files

by Sven Van Caekenberghe

There are a lot of questions in there, too much to answer. The basic answer is that everything is modelled as objects, even the objects themselves. There is a complete meta model of what could be considered code and even the execution of code. Furthermore, even versioning is modelled nicely too. Of course, Pharo interfaces with the outside world, it can read and write files, it can do networking. The object world and its code can, in various ways, be mapped to concepts of this world. For example, https://github.com/pharo-project/pharo-core contains (a copy, one representation) of all code in Pharo. There is also the option to save the whole object world to a single snapshot file, called an image. Running on servers, containers, embedded devices is all possible, in multiple ways, with or without a (G)UI. At that point Pharo consists of a couple of files, most notably the image file. HTH, Sven > On 06 Dec 2015, at 17:58, horrido <horrido.hobbies(a)gmail.com> wrote: > > I submitted an article at Reddit called "Stop Thinking in Terms of Files." > Some guy with the handle "audioen" wrote the following comment: > > We have heard that smalltalk appears to use model similar to a LISP machine > of yore in that the programming environment = the OS = the runtime > environment. Once you define a function, it simply exists without being > written to a file or compiled into some process that runs it. You can just > call it, or undefine it and it ceases to be. From this point of view, it is > probably perfectly valid to say that it has no files, because it doesn't > need them. > > On the other hand, let's assume that your smalltalk image got a little bit > corrupted so that some packages/functions/whatever are now missing or not > functioning. Or, let's say that you accidentally undefined a function and > that was a mistake and now you really want to get it back. How would you do > that? The file-based answer is that you hopefully had backups of the files > that held definition of that function. What passes for a backup in smalltalk > land? > > And how do you deal with version control? How do you recover from mistakes? > If you wanted to share your crap to someone else collaboratively through > e.g. github, how would you do that? You'd have to export your functions into > individual files, probably, and packages as directories into git. Someone > would check them out, eval them, make changes, and commit updated functions. > How does this kind of process look like, in a non-file paradigm, if it is > done at all? (Does smalltalk VM even support networking?) > > In general how do you even dump the state of the VM in some way that you can > show someone what exactly your project is made of, in textual form? It's not > very nice to dump an entire image and tell them to just run that. I bet the > image is much larger and contains historical stuff that you no longer care > about. What if you really just wanted to publish a recipe that can construct > something equivalent of that particular image? What does "docker" for > smalltalk look like? > > If you tell us files suck, tell us also how you solve the same problems that > we solve through files. Especially that collaborative programming through > github use case interests me a little. > ----- > > I must confess, I'm not fully qualified to answer this comment, /at least, > not optimally/. Perhaps some of you can go to the Reddit link > <https://www.reddit.com/r/programming/comments/3vjlta/stop_thinking_in_terms…> > and respond? Thanks. > > > > -- > View this message in context: http://forum.world.st/Stop-Thinking-in-Terms-of-Files-tp4865614.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Dec. 6, 2015

Re: [Pharo-users] OrderedSet?

by HernÃ¡n Morales Durand

Have a look at: http://www.mail-archive.com/help-smalltalk@gnu.org/msg01225.html http://www.squeaksource.com/PharoTaskForces.html http://www.smalltalkhub.com/#!/~Moose/CollectionExtensions HernÃ¡n 2015-12-05 23:21 GMT-03:00 Peter Uhnak <i.uhnak(a)gmail.com>: > Hi, > > what would be the equivalent of an OrderedSet? > > 1. all elements are unique > > 2. they are ordered > > 3. adding an existing element moves it > so > myOrderedSet addLast: x. "<- x is added as last" > myOrderedSet addFirst: x. "<- x is moved from last to first" > > Thanks, > > -- > Peter > >

Dec. 6, 2015

Stop Thinking in Terms of Files

by horrido

I submitted an article at Reddit called "Stop Thinking in Terms of Files." Some guy with the handle "audioen" wrote the following comment: We have heard that smalltalk appears to use model similar to a LISP machine of yore in that the programming environment = the OS = the runtime environment. Once you define a function, it simply exists without being written to a file or compiled into some process that runs it. You can just call it, or undefine it and it ceases to be. From this point of view, it is probably perfectly valid to say that it has no files, because it doesn't need them. On the other hand, let's assume that your smalltalk image got a little bit corrupted so that some packages/functions/whatever are now missing or not functioning. Or, let's say that you accidentally undefined a function and that was a mistake and now you really want to get it back. How would you do that? The file-based answer is that you hopefully had backups of the files that held definition of that function. What passes for a backup in smalltalk land? And how do you deal with version control? How do you recover from mistakes? If you wanted to share your crap to someone else collaboratively through e.g. github, how would you do that? You'd have to export your functions into individual files, probably, and packages as directories into git. Someone would check them out, eval them, make changes, and commit updated functions. How does this kind of process look like, in a non-file paradigm, if it is done at all? (Does smalltalk VM even support networking?) In general how do you even dump the state of the VM in some way that you can show someone what exactly your project is made of, in textual form? It's not very nice to dump an entire image and tell them to just run that. I bet the image is much larger and contains historical stuff that you no longer care about. What if you really just wanted to publish a recipe that can construct something equivalent of that particular image? What does "docker" for smalltalk look like? If you tell us files suck, tell us also how you solve the same problems that we solve through files. Especially that collaborative programming through github use case interests me a little. ----- I must confess, I'm not fully qualified to answer this comment, /at least, not optimally/. Perhaps some of you can go to the Reddit link <https://www.reddit.com/r/programming/comments/3vjlta/stop_thinking_in_terms…> and respond? Thanks. -- View this message in context: http://forum.world.st/Stop-Thinking-in-Terms-of-Files-tp4865614.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 6, 2015