Again, you seem to be using "the image" mainly to mean "the .image file", and only occassionally to mean the actual image itself. They are distinct (albeit tightly related) things. On 7 Dec 2015 22:09, "Dimitris Chloupis" <[email protected]> wrote:
> And this "victory of dead code and date" that files usually promote can > further benefit Pharo . > > For example lets take one of the main problems of the Pharo image, its > size. There is already an effort to modularilise the image to make it small > and everything else installable and unistallable. > > But why not go a step further and have dead zone files. So you end up with > a tiny image containing just the basics (few kbs if possible) even no GUI > and IDE tools and instead you have a collection of files that can be read > by the image , each file contains a diffirent project, you can view their > code and their data but not install them in the image to do so. And only > when you decide that "sure I could use this project" then you instruct the > image to import the file and make the code and the data live and part of > the image. This way the pharo system can keep growing without growing the > image at all and let the users decide how much they want to grow the image > themselves. > > Technically speaking this functionality is already available through > monticello , where monticello allow you to view a local or remote > repository of code without loading the code to the image (via the "open > button"). So its not even a new concept. Though in my mind I imagine all > this happening from inside the System Browser. > > Thats just one scenario how dead data and code can greatly benefit the > Pharo system. I can keep brainstorming forever for the usefulness of files > for Pharo. > > > On Mon, Dec 7, 2015 at 9:20 PM horrido <[email protected]> wrote: > >> 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. >> >>
