December 2015 - Pharo-users

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

by EuanM

> Look man you do more harm with these articles than you do good. No. Just... no. > This Smalltalk hype is the worst of its kind and completely misses the point of why Smalltalk is great. Speaking of "hype(rbole)"... On 6 December 2015 at 19:58, Dimitris Chloupis <kilon.alios(a)gmail.com> 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. > > 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. 7, 2015

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

by EuanM

>An image IS a file !!! An image *can be stored to* a file. The image is not the file. Ceci n'est pas une pipe. The reason it is image-based is that the image is the primary representation. The copy of the image stored in a file is simply a persisting back-up of the image. Unlike file based systems like, say an SQL d/b. There, the file is the primary representation, and what is in memory is (generally) both transient and partial. (i.e. we load in things from disk, and write things out to disk, and the disk is the canonical representation of the state. With the image based system, the file-copy of the image is transient and often partial. The 'image' of the system (i.e. the current state of system and contents that is held in memory (including anything paged out to store in virtual memory) is the primary representation, and the canonical representation of state. (Although it could be that the changes file is kept in lock-step automagically - I've never looked into what the changes file is actually doing at a moment-to--moment level, at which point the changes file would be partial and capable of generating or providing a canonical representation of state ). On 6 December 2015 at 19:58, Dimitris Chloupis <kilon.alios(a)gmail.com> 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. > > 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. 7, 2015

VM on Fedora 22

by KlÃ©risson PaixÃ£o

Hey! Did anyone face such error trying to compile the VM: Mpeg3Plugin/libMpeg3Plugin.a(reconstruct.c.o): In function `mpeg3video_reconstruct': reconstruct.c:(.text+0x1788): undefined reference to `mpeg3video_calc_dmv' reconstruct.c:(.text+0x1cb9): undefined reference to `mpeg3video_calc_dmv' Workarounds? Cheers, KlÃ©risson

Dec. 7, 2015

Re: [Pharo-users] Roassal Performance Issues when applying layout

by Alejandro Infante

Hi, It is really difficult to help you just with a profile and without looking at your code. Even though, I have noticed that most of the time is used on calculating properties related to CompositeShapes (like position and encompassing rectangle). Would be possible for you to run the same code but replacing the CompositeShape by another less complex shape (like RTBox)? If this new experiment is fast, then the problem would be those 2 properties (position and encompassing rectangle) are too expensive, and therefore we should think how to optimize that code. I know that ForceLayout is not the fastest layout, but 59 seconds is too much for just 13 elements. Cheers, Alejandro > On Dec 7, 2015, at 5:26 PM, Pablo Polanco <paropoga(a)gmail.com> wrote: > > Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer Science students at Universidad de Chile. > > We are currently taking a course on Robotics Software Engineering dictated by Johan Fabry. > > We want to visualize a simple directed graph and we are experiencing performance issues when layouting our visualization in Roassal. > > We provide the report from the Time Profiler when we visualize 13 elements and 38 edges: http://pastebin.com/zsh8YFPx <http://pastebin.com/zsh8YFPx> > > Should it take so much time? How could we improve it? Is there another more appropriate layout? > > Thanks in advance :) > > <Screenshot from 2015-12-07 17:23:05.png> > â

Dec. 7, 2015

Roassal Performance Issues when applying layout

by Pablo Polanco

Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer Science students at Universidad de Chile. We are currently taking a course on Robotics Software Engineering dictated by Johan Fabry. We want to visualize a simple directed graph and we are experiencing performance issues when layouting our visualization in Roassal. We provide the report from the Time Profiler when we visualize 13 elements and 38 edges: http://pastebin.com/zsh8YFPx Should it take so much time? How could we improve it? Is there another more appropriate layout? Thanks in advance :) â

Dec. 7, 2015

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

by horrido

You make a convincing argument. Files are useful. In modern circumstances, Smalltalk has to coexist with a file-based world. As Joachim wrote earlier, we are well-equipped to deal with files, but we do not think in terms of files when we code our applications. We are not obliged to use a file-based toolchain. The point of my article was to persuade other developers that letting their obsession with file-based tools prevent them from adopting Smalltalk is short-sighted and counter-productive. Files have their uses, but they should look beyond files for other software creation possibilities. Smalltalk has much to offer. And, yes, it would be very good to have 64-bit support in Smalltalk. kilon.alios wrote > The devil is in the details ;) > > It matters to me, I just came across the need to share data between > multiple images. So I was pointed by the good people here to the Fuel > library that , surprise surprise , it generates binary files that contain > objects in their live state that helps you move and share code and data > between images. Works well and I really like its design :) > > We are not talking here about something sophisticated, we are talking here > super basic functionality. Images sharing data and code. What we use ? > Files. The image by itself has no functionality to even cover this super > basic scenario because as a format is made to be self contained. > > How you cant even care for such basic functionality ? Of course you will > at > some point. Its unavoidable. > > The nice thing about files is that they have one very big advantage over > the image. That is, specialization. When an app find a specific file , > just > by looking at its extension it immediately knows the structure of the data > and the code that it may contain. > > On other hand when you have an object system like the image is, such > specifications go outside the window meaning you have to deal with the > fact > and trust that those that made those images have adhered to specific > guidelines so you can make sure that your code wont run in front of some > very nasty surprises. > > But since the image itself allow you hack so deeply as the syntax of the > language , you can't be sure how the data and code will be presented. Sure > they will objects, but the format does not really matter so much as the > structure itself. > > In those cases files win hands down because they tend to be far more > restricted on how they are structured. Not because there is anything > special to these files, apart from the fact that their authors made sure > to > follow the specific structure to ensure compatibility with third party > apps. > > So not only Files are not on the Stone Age but they have evolved the level > of specification to a whole new level that have made the foundation of our > every day lives. > > Sure you could probably replace files with a new way that is more > Smalltalk > friendly and still retain all the advantages of files and file system but > , > Smalltalk has not presented such solution to my knowledge. Hence we the > smalltalkers we will still keep relying heavily on files for our every day > needs until such solution is presented to us. Also with the huge wealth of > file formats it would be a pain in the ass to replace them with a > smalltalk > solution. > > In the mean time there are even more pressing matter that the image file > has to attend to, which is far more stone age , to use your remark , than > files. That is the ability to use full memory of the system and the > ability > to deal with large data without any large hits on performance. In short > good support for 64 bit and big data. > > > "But these are implementation details...implementation of the base system. > /From the perspective of a programmer writing an application/, none of > this > matters. > > As I said earlier, the only reason why Smalltalk has to deal with files at > all is because we live in a file-based culture. And the reason our culture > is so entrenched with files is because we are too heavily invested in > them, > and we aren't going to budge. *Files are about as low a storage > abstraction > as you can get*, and they pre-date even Unix. Yes, files belong in the > Stone > Age!" > > On Mon, Dec 7, 2015 at 6:45 PM horrido < > horrido.hobbies@ > > wrote: > >> But these are implementation details...implementation of the base system. >> /From the perspective of a programmer writing an application/, none of >> this >> matters. >> >> As I said earlier, the only reason why Smalltalk has to deal with files >> at >> all is because we live in a file-based culture. And the reason our >> culture >> is so entrenched with files is because we are too heavily invested in >> them, >> and we aren't going to budge. *Files are about as low a storage >> abstraction >> as you can get*, and they pre-date even Unix. Yes, files belong in the >> Stone >> Age! >> >> >> >> kilon.alios wrote >> > That's the thing you can't take the argument further without >> diminishing >> > the value of you argument precisely for the fact that the vm is far >> closer >> > related to the image than it is to 0s and 1s. That tight relation is >> > fundamental to the behavior and existence of the image. It defines its >> > functionality, purpose and limitations. >> > >> > The image itself is a file and the fact that it can store live state in >> a >> > binary format does not make it unique or any less of a file. In my case >> I >> > use blender files, they store the entire live state of the blender >> window >> > including images and even Python scripts. Similar examples are >> countless >> > out there. >> > >> > So the answer to the question what makes the image file format unique >> is >> > simply.... Nothing >> > What's the advantage of using the image format compared to other files >> ? >> > None >> > >> > On Mon, 7 Dec 2015 at 15:14, Ben Coman < >> >> > btc@ >> >> > > wrote: >> > >> >> On Mon, Dec 7, 2015 at 3:37 PM, Dimitris Chloupis < >> >> > kilon.alios@ >> >> > > >> >> wrote: >> >> > "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." >> >> > >> >> > >> >> > Thats not the case even for someone like me that has been working >> with >> >> > smalltalk for only 2 years. The Image is not even the engine that >> >> drives >> >> > smalltalk . Thats the job of the VM that exists in a completely >> >> different >> >> > universe than smalltalk. It exists in the same universe than many >> other >> >> > languages do exists and thats the C universe, the universe of the >> OS. >> >> > Essentially what drives your system is not smalltalk is C. The >> >> diffirence is >> >> > that for a part of it that is high level enough, Slang is used, a >> >> Hybrid >> >> > language between C and Smalltalk that compiles to C. So while in the >> >> image >> >> > everything is , well almost everything, an object all the way down, >> in >> >> the >> >> > VM everything is C all the way down. >> >> >> >> To take that argument further, the VM is not even the thing driving >> >> the image ;). Essentially what drives it are the 1's and 0's of >> >> machine code. Further, what drives that are the electrons flowing >> >> through the chip. I think its fair to say that we *code* in Pharo >> >> without files. Files relate to Pharo only to the same extent that a >> >> database like Oracle or Postgres can be said to use files. That is, >> >> when you do SQL queries, are you *thinking* in terms of files, even >> >> though files are used by the server to store the data? Its just a >> >> matter of where you draw the line of abstraction. >> >> >> >> cheers -ben >> >> >> >> > Ironically an image misses the most important tool to even generate >> >> this >> >> C >> >> > code and thats the VMMaker that has to be installed separately. And >> of >> >> > course there are parts of the system that are coded in pure C, like >> >> some >> >> > core functionalities of the VM and of course plugins and external >> >> libraries >> >> > that the image has to rely on make things happen. >> >> > >> >> > Of course the image is still fairly powerful, you can change the >> >> syntax, >> >> > implement high level libraries, IDE tools and much more. But its not >> >> the >> >> > core of the system just another essential part of it. >> >> > >> >> > >> >> > On Mon, Dec 7, 2015 at 9:24 AM Dimitris Chloupis < >> >> > kilon.alios@ >> >> > > >> >> > wrote: >> >> >>> >> >> >>> >> >> >>> well, i wouldn't need or even want it in memory, so on disk is >> fine. >> >> the >> >> >>> problem is more likely management of the same. browsing the >> changes >> >> is >> >> >>> not >> >> >>> really convenient. ideally i'd like to see versions in the >> >> class-browser >> >> >>> and >> >> >>> in the debugger, where on error i could then take a look at older >> >> >>> versions for >> >> >>> comparison, and switch to them to see if maybe the last change was >> >> the >> >> >>> cause of >> >> >>> the error. >> >> >>> >> >> >>> greetings, martin. >> >> >>> >> >> >> >> >> >> There are versions already for methods. So the functionality is >> there. >> >> >> >> >> >> I disagree however with you, I think that changes file was created >> for >> >> the >> >> >> precise scenarios of an image crash/ lockdown. In that case you may >> >> want to >> >> >> go back through the code and dont remember which method was >> triggered >> >> or >> >> >> what else was defined and created. In the case going >> chronologically >> >> which >> >> >> is how the changes file is already organised is far more useful >> than >> >> going >> >> >> method and class based. >> >> >> >> >> >> But I do agree it would be useful to extend the tools working with >> >> changes >> >> >> , but then none stop anyone from doing so and is not that hard to >> do. >> >> >> >> >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Stop-Thinking-in-Terms-of-Files-tp4865614p4865820.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> -- View this message in context: http://forum.world.st/Stop-Thinking-in-Terms-of-Files-tp4865614p4865872.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 7, 2015

Re: [Pharo-users] [squeak-dev] Name change: Mushroom ( was Re: evolutions of squeakelib & crypto)

by Sven Van Caekenberghe

http://catalog.pharo.org is a partial answer, it is also available in-image: > On 07 Dec 2015, at 18:52, Todd Blanchard <tblanchard(a)mac.com> wrote: > > Sigh. > > I wish people would choose descriptive names for their projects. I went looking on Smalltalkhub for some capability and what I found are thousands of packages with names that mean nothing and no description entered either. If you want to make sure nobody ever uses your code you've just taken a giant step in the right direction. But if you hope to make something lots of people benefit from - nobody is going to look for "mushroom" when they want crypto capabilities. > > Sorry, this has been really bugging me lately. We, as a community, do a lousy job of making our code easy to find. > > -Todd Blanchard > >> On Dec 7, 2015, at 07:38, Ben Coman <btc(a)openInWorld.com> wrote: >> >> I like it, but it seems you missed my point :) >> mushroom --> 117,000,000 is two orders of magnitude more hidden. >> Anyway, maybe I overplay its significance. >> cheers -ben >> >> On Mon, Dec 7, 2015 at 11:11 PM, Robert Withers >> <robert.w.withers(a)gmail.com> wrote: >>> I renamed the project to Mushroom and I also dumped the encoding work to >>> focus on shutdown, optimization and serialization. Here's the wiki: >>> https://github.com/SqueakCryptographySquad/Mushroom/wiki >>> >>> thanks,Robert >>> >>> >>> On 12/06/2015 01:42 AM, Ben Coman wrote: >>>> >>>> On Sun, Dec 6, 2015 at 10:42 AM, Robert Withers >>>> <robert.w.withers(a)gmail.com> wrote: >>>>> >>>>> On 12/05/2015 09:24 PM, Ben Coman wrote: >>>>>> >>>>>> On Fri, Dec 4, 2015 at 11:57 PM, Robert Withers >>>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>>> >>>>>>> Now I think you are right on with your observation. Additionally, the >>>>>>> number >>>>>>> of dialects could increase further with Fuel serialization, just port >>>>>>> SecureSession and bits. >>>>>>> >>>>>>> Alright, I came up with a name and it may border on the egregious ... >>>>>>> presenting ... >>>>>>> >>>>>>> "Maelstrom" >>>>>> >>>>>> Great sounding name. However some general advice for the community, >>>>>> since I see a lot of great sounding project names drowned out in the >>>>>> noise of our web-search-centric universe. A litmus test for project >>>>>> naming is using google search to find which return low search results. >>>>>> Today, its more important to be unique than any other attribute of a >>>>>> name. So in general, *dictionary* english words are not the best. >>>>>> One technique is to intentionally mispell the word you like. Here are >>>>>> some comparative examples (note, the surrounding quotes are required >>>>>> to avoid google trying to be helpful and correct the spelling)... >>>>>> >>>>>> "maelstrom" --> 7,480,000 >>>>>> "maelstroom" --> 6,200 >>>>>> "maelstrum" --> 2,280 >>>>>> "maelstruum" --> 7 >>>>>> >>>>>> Lots of interesting other techniques can be found by searching on: >>>>>> techniques to generate brand names or domain names. >>>>>> >>>>>> cheers -ben >>>>> >>>>> >>>>> I would be happy to change the names to something more unique, though it >>>>> may >>>>> take a few. Are you suggesting "maelstruum"? >>>>> >>>>> cheers, >>>>> Robert >>>>> >>>>> >>>> *Suggesting* yes, but the choice is yours ;) You need to own it. >>>> >>>> I think maelstruum is certainly memorable with the double "u", but >>>> maybe jarring next the the "m". I'm inclined to maelstroom, since I >>>> associate it with "zoom". I wouldn't necessarily go for the absolute >>>> lowest results. I have an entirely unsubstantiated belief that >>>> anything less than 10,000 gives a reasonable chance to compete once a >>>> user's browsing history is taken into account. Finally you need to >>>> check existing results don't return something abhorrent (I didn't do >>>> this). >>>> >>>> I'd encourage to play around testing on google search. Its quick and >>>> easy to generate and test alternatives. I've added a few more below. >>>> "maelstra" --> 3,560 >>>> "maelstram" --> 504 >>>> "maelstrim" --> 1200 >>>> "maelstroon" --> 58 >>>> "maelstroomi" --> 4 >>>> >>>> btw, I wouldn't swap the order of the "ae" since that would be >>>> susceptible to real typing errors. >>>> >>>> cheers -ben >>>> >>> >>> >> > >

Dec. 7, 2015

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

by Dimitris Chloupis

The devil is in the details ;) It matters to me, I just came across the need to share data between multiple images. So I was pointed by the good people here to the Fuel library that , surprise surprise , it generates binary files that contain objects in their live state that helps you move and share code and data between images. Works well and I really like its design :) We are not talking here about something sophisticated, we are talking here super basic functionality. Images sharing data and code. What we use ? Files. The image by itself has no functionality to even cover this super basic scenario because as a format is made to be self contained. How you cant even care for such basic functionality ? Of course you will at some point. Its unavoidable. The nice thing about files is that they have one very big advantage over the image. That is, specialization. When an app find a specific file , just by looking at its extension it immediately knows the structure of the data and the code that it may contain. On other hand when you have an object system like the image is, such specifications go outside the window meaning you have to deal with the fact and trust that those that made those images have adhered to specific guidelines so you can make sure that your code wont run in front of some very nasty surprises. But since the image itself allow you hack so deeply as the syntax of the language , you can't be sure how the data and code will be presented. Sure they will objects, but the format does not really matter so much as the structure itself. In those cases files win hands down because they tend to be far more restricted on how they are structured. Not because there is anything special to these files, apart from the fact that their authors made sure to follow the specific structure to ensure compatibility with third party apps. So not only Files are not on the Stone Age but they have evolved the level of specification to a whole new level that have made the foundation of our every day lives. Sure you could probably replace files with a new way that is more Smalltalk friendly and still retain all the advantages of files and file system but , Smalltalk has not presented such solution to my knowledge. Hence we the smalltalkers we will still keep relying heavily on files for our every day needs until such solution is presented to us. Also with the huge wealth of file formats it would be a pain in the ass to replace them with a smalltalk solution. In the mean time there are even more pressing matter that the image file has to attend to, which is far more stone age , to use your remark , than files. That is the ability to use full memory of the system and the ability to deal with large data without any large hits on performance. In short good support for 64 bit and big data. "But these are implementation details...implementation of the base system. /From the perspective of a programmer writing an application/, none of this matters. As I said earlier, the only reason why Smalltalk has to deal with files at all is because we live in a file-based culture. And the reason our culture is so entrenched with files is because we are too heavily invested in them, and we aren't going to budge. *Files are about as low a storage abstraction as you can get*, and they pre-date even Unix. Yes, files belong in the Stone Age!" On Mon, Dec 7, 2015 at 6:45 PM horrido <horrido.hobbies(a)gmail.com> wrote: > But these are implementation details...implementation of the base system. > /From the perspective of a programmer writing an application/, none of this > matters. > > As I said earlier, the only reason why Smalltalk has to deal with files at > all is because we live in a file-based culture. And the reason our culture > is so entrenched with files is because we are too heavily invested in them, > and we aren't going to budge. *Files are about as low a storage abstraction > as you can get*, and they pre-date even Unix. Yes, files belong in the > Stone > Age! > > > > kilon.alios wrote > > That's the thing you can't take the argument further without diminishing > > the value of you argument precisely for the fact that the vm is far > closer > > related to the image than it is to 0s and 1s. That tight relation is > > fundamental to the behavior and existence of the image. It defines its > > functionality, purpose and limitations. > > > > The image itself is a file and the fact that it can store live state in a > > binary format does not make it unique or any less of a file. In my case I > > use blender files, they store the entire live state of the blender window > > including images and even Python scripts. Similar examples are countless > > out there. > > > > So the answer to the question what makes the image file format unique is > > simply.... Nothing > > What's the advantage of using the image format compared to other files ? > > None > > > > On Mon, 7 Dec 2015 at 15:14, Ben Coman < > > > btc@ > > > > wrote: > > > >> On Mon, Dec 7, 2015 at 3:37 PM, Dimitris Chloupis < > > > kilon.alios@ > > > > > >> wrote: > >> > "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." > >> > > >> > > >> > Thats not the case even for someone like me that has been working with > >> > smalltalk for only 2 years. The Image is not even the engine that > >> drives > >> > smalltalk . Thats the job of the VM that exists in a completely > >> different > >> > universe than smalltalk. It exists in the same universe than many > other > >> > languages do exists and thats the C universe, the universe of the OS. > >> > Essentially what drives your system is not smalltalk is C. The > >> diffirence is > >> > that for a part of it that is high level enough, Slang is used, a > >> Hybrid > >> > language between C and Smalltalk that compiles to C. So while in the > >> image > >> > everything is , well almost everything, an object all the way down, in > >> the > >> > VM everything is C all the way down. > >> > >> To take that argument further, the VM is not even the thing driving > >> the image ;). Essentially what drives it are the 1's and 0's of > >> machine code. Further, what drives that are the electrons flowing > >> through the chip. I think its fair to say that we *code* in Pharo > >> without files. Files relate to Pharo only to the same extent that a > >> database like Oracle or Postgres can be said to use files. That is, > >> when you do SQL queries, are you *thinking* in terms of files, even > >> though files are used by the server to store the data? Its just a > >> matter of where you draw the line of abstraction. > >> > >> cheers -ben > >> > >> > Ironically an image misses the most important tool to even generate > >> this > >> C > >> > code and thats the VMMaker that has to be installed separately. And of > >> > course there are parts of the system that are coded in pure C, like > >> some > >> > core functionalities of the VM and of course plugins and external > >> libraries > >> > that the image has to rely on make things happen. > >> > > >> > Of course the image is still fairly powerful, you can change the > >> syntax, > >> > implement high level libraries, IDE tools and much more. But its not > >> the > >> > core of the system just another essential part of it. > >> > > >> > > >> > On Mon, Dec 7, 2015 at 9:24 AM Dimitris Chloupis < > > > kilon.alios@ > > > > > >> > wrote: > >> >>> > >> >>> > >> >>> well, i wouldn't need or even want it in memory, so on disk is fine. > >> the > >> >>> problem is more likely management of the same. browsing the changes > >> is > >> >>> not > >> >>> really convenient. ideally i'd like to see versions in the > >> class-browser > >> >>> and > >> >>> in the debugger, where on error i could then take a look at older > >> >>> versions for > >> >>> comparison, and switch to them to see if maybe the last change was > >> the > >> >>> cause of > >> >>> the error. > >> >>> > >> >>> greetings, martin. > >> >>> > >> >> > >> >> There are versions already for methods. So the functionality is > there. > >> >> > >> >> I disagree however with you, I think that changes file was created > for > >> the > >> >> precise scenarios of an image crash/ lockdown. In that case you may > >> want to > >> >> go back through the code and dont remember which method was triggered > >> or > >> >> what else was defined and created. In the case going chronologically > >> which > >> >> is how the changes file is already organised is far more useful than > >> going > >> >> method and class based. > >> >> > >> >> But I do agree it would be useful to extend the tools working with > >> changes > >> >> , but then none stop anyone from doing so and is not that hard to do. > >> > >> > > > > > > -- > View this message in context: > http://forum.world.st/Stop-Thinking-in-Terms-of-Files-tp4865614p4865820.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Dec. 7, 2015

Re: [Pharo-users] [squeak-dev] Name change: Mushroom ( was Re: evolutions of squeakelib & crypto)

by Todd Blanchard

Sigh. I wish people would choose descriptive names for their projects. I went looking on Smalltalkhub for some capability and what I found are thousands of packages with names that mean nothing and no description entered either. If you want to make sure nobody ever uses your code you've just taken a giant step in the right direction. But if you hope to make something lots of people benefit from - nobody is going to look for "mushroom" when they want crypto capabilities. Sorry, this has been really bugging me lately. We, as a community, do a lousy job of making our code easy to find. -Todd Blanchard > On Dec 7, 2015, at 07:38, Ben Coman <btc(a)openInWorld.com> wrote: > > I like it, but it seems you missed my point :) > mushroom --> 117,000,000 is two orders of magnitude more hidden. > Anyway, maybe I overplay its significance. > cheers -ben > > On Mon, Dec 7, 2015 at 11:11 PM, Robert Withers > <robert.w.withers(a)gmail.com> wrote: >> I renamed the project to Mushroom and I also dumped the encoding work to >> focus on shutdown, optimization and serialization. Here's the wiki: >> https://github.com/SqueakCryptographySquad/Mushroom/wiki >> >> thanks,Robert >> >> >> On 12/06/2015 01:42 AM, Ben Coman wrote: >>> >>> On Sun, Dec 6, 2015 at 10:42 AM, Robert Withers >>> <robert.w.withers(a)gmail.com> wrote: >>>> >>>> On 12/05/2015 09:24 PM, Ben Coman wrote: >>>>> >>>>> On Fri, Dec 4, 2015 at 11:57 PM, Robert Withers >>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>> >>>>>> Now I think you are right on with your observation. Additionally, the >>>>>> number >>>>>> of dialects could increase further with Fuel serialization, just port >>>>>> SecureSession and bits. >>>>>> >>>>>> Alright, I came up with a name and it may border on the egregious ... >>>>>> presenting ... >>>>>> >>>>>> "Maelstrom" >>>>> >>>>> Great sounding name. However some general advice for the community, >>>>> since I see a lot of great sounding project names drowned out in the >>>>> noise of our web-search-centric universe. A litmus test for project >>>>> naming is using google search to find which return low search results. >>>>> Today, its more important to be unique than any other attribute of a >>>>> name. So in general, *dictionary* english words are not the best. >>>>> One technique is to intentionally mispell the word you like. Here are >>>>> some comparative examples (note, the surrounding quotes are required >>>>> to avoid google trying to be helpful and correct the spelling)... >>>>> >>>>> "maelstrom" --> 7,480,000 >>>>> "maelstroom" --> 6,200 >>>>> "maelstrum" --> 2,280 >>>>> "maelstruum" --> 7 >>>>> >>>>> Lots of interesting other techniques can be found by searching on: >>>>> techniques to generate brand names or domain names. >>>>> >>>>> cheers -ben >>>> >>>> >>>> I would be happy to change the names to something more unique, though it >>>> may >>>> take a few. Are you suggesting "maelstruum"? >>>> >>>> cheers, >>>> Robert >>>> >>>> >>> *Suggesting* yes, but the choice is yours ;) You need to own it. >>> >>> I think maelstruum is certainly memorable with the double "u", but >>> maybe jarring next the the "m". I'm inclined to maelstroom, since I >>> associate it with "zoom". I wouldn't necessarily go for the absolute >>> lowest results. I have an entirely unsubstantiated belief that >>> anything less than 10,000 gives a reasonable chance to compete once a >>> user's browsing history is taken into account. Finally you need to >>> check existing results don't return something abhorrent (I didn't do >>> this). >>> >>> I'd encourage to play around testing on google search. Its quick and >>> easy to generate and test alternatives. I've added a few more below. >>> "maelstra" --> 3,560 >>> "maelstram" --> 504 >>> "maelstrim" --> 1200 >>> "maelstroon" --> 58 >>> "maelstroomi" --> 4 >>> >>> btw, I wouldn't swap the order of the "ae" since that would be >>> susceptible to real typing errors. >>> >>> cheers -ben >>> >> >> >

Dec. 7, 2015

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

by horrido

But these are implementation details...implementation of the base system. /From the perspective of a programmer writing an application/, none of this matters. As I said earlier, the only reason why Smalltalk has to deal with files at all is because we live in a file-based culture. And the reason our culture is so entrenched with files is because we are too heavily invested in them, and we aren't going to budge. *Files are about as low a storage abstraction as you can get*, and they pre-date even Unix. Yes, files belong in the Stone Age! kilon.alios wrote > That's the thing you can't take the argument further without diminishing > the value of you argument precisely for the fact that the vm is far closer > related to the image than it is to 0s and 1s. That tight relation is > fundamental to the behavior and existence of the image. It defines its > functionality, purpose and limitations. > > The image itself is a file and the fact that it can store live state in a > binary format does not make it unique or any less of a file. In my case I > use blender files, they store the entire live state of the blender window > including images and even Python scripts. Similar examples are countless > out there. > > So the answer to the question what makes the image file format unique is > simply.... Nothing > What's the advantage of using the image format compared to other files ? > None > > On Mon, 7 Dec 2015 at 15:14, Ben Coman < > btc@ > > wrote: > >> On Mon, Dec 7, 2015 at 3:37 PM, Dimitris Chloupis < > kilon.alios@ > > >> wrote: >> > "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." >> > >> > >> > Thats not the case even for someone like me that has been working with >> > smalltalk for only 2 years. The Image is not even the engine that >> drives >> > smalltalk . Thats the job of the VM that exists in a completely >> different >> > universe than smalltalk. It exists in the same universe than many other >> > languages do exists and thats the C universe, the universe of the OS. >> > Essentially what drives your system is not smalltalk is C. The >> diffirence is >> > that for a part of it that is high level enough, Slang is used, a >> Hybrid >> > language between C and Smalltalk that compiles to C. So while in the >> image >> > everything is , well almost everything, an object all the way down, in >> the >> > VM everything is C all the way down. >> >> To take that argument further, the VM is not even the thing driving >> the image ;). Essentially what drives it are the 1's and 0's of >> machine code. Further, what drives that are the electrons flowing >> through the chip. I think its fair to say that we *code* in Pharo >> without files. Files relate to Pharo only to the same extent that a >> database like Oracle or Postgres can be said to use files. That is, >> when you do SQL queries, are you *thinking* in terms of files, even >> though files are used by the server to store the data? Its just a >> matter of where you draw the line of abstraction. >> >> cheers -ben >> >> > Ironically an image misses the most important tool to even generate >> this >> C >> > code and thats the VMMaker that has to be installed separately. And of >> > course there are parts of the system that are coded in pure C, like >> some >> > core functionalities of the VM and of course plugins and external >> libraries >> > that the image has to rely on make things happen. >> > >> > Of course the image is still fairly powerful, you can change the >> syntax, >> > implement high level libraries, IDE tools and much more. But its not >> the >> > core of the system just another essential part of it. >> > >> > >> > On Mon, Dec 7, 2015 at 9:24 AM Dimitris Chloupis < > kilon.alios@ > > >> > wrote: >> >>> >> >>> >> >>> well, i wouldn't need or even want it in memory, so on disk is fine. >> the >> >>> problem is more likely management of the same. browsing the changes >> is >> >>> not >> >>> really convenient. ideally i'd like to see versions in the >> class-browser >> >>> and >> >>> in the debugger, where on error i could then take a look at older >> >>> versions for >> >>> comparison, and switch to them to see if maybe the last change was >> the >> >>> cause of >> >>> the error. >> >>> >> >>> greetings, martin. >> >>> >> >> >> >> There are versions already for methods. So the functionality is there. >> >> >> >> I disagree however with you, I think that changes file was created for >> the >> >> precise scenarios of an image crash/ lockdown. In that case you may >> want to >> >> go back through the code and dont remember which method was triggered >> or >> >> what else was defined and created. In the case going chronologically >> which >> >> is how the changes file is already organised is far more useful than >> going >> >> method and class based. >> >> >> >> But I do agree it would be useful to extend the tools working with >> changes >> >> , but then none stop anyone from doing so and is not that hard to do. >> >> -- View this message in context: http://forum.world.st/Stop-Thinking-in-Terms-of-Files-tp4865614p4865820.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 7, 2015