Pharo-users

By thread

pharo-users@lists.pharo.org

December 2015

85 participants
655 messages

Roassal: Multiple Nesting

by Leonel Merino

Hi all, I want to visualise three nested levels of a model. I am not sure if I am doing it right, since I had to add a reference to the view to the nested elements manually to make it work. The problem I face now is that elements in the deepest level do not react to interactions. In the example below, popup is only shown for the elements in the first two levels. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= v := RTView new. es := (RTBox new color: Color white; borderColor: Color lightGray) elementsOn: (Array with: RTLayout with: RTShape with: RTBuilder). v addAll: es. es @ RTPopup. RTNest new for: es add: [ :group :model | elements := (RTBox new color: (Color red alpha: 0.1)) elementsOn: model withAllSubclasses. group addAll: elements. elements @ RTPopup. elements do: [ :e | e view: v ]. RTNest new for: elements add: [ :group2 :model2 | els := (RTBox new color: Color blue) elementsOn: model2 methods. group2 addAll: els. els @ RTPopup. RTTreeLayout on: els edges: edges ]. RTGridLayout on: elements ]. RTGridLayout on: es. v -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Any hint would be much appreciated. Best regards, Leonel

Dec. 8, 2015

Re: [Pharo-users] Datatables

by Mariano Martinez Peck

Hi guys, Pablo was asking about Datatables which is a JS plugin, not databases :) Pablo, In Smalltalk hub there are a couple of DataTables projects. It would be interesting to know which one is the "official". Second, please ask in Seaside mailing list. For my client, I forked the original DatatablesFileLibrary because I needed extra plugins. And then, I simple used JS. So the steps are simply add the file library into the libs of your app. Then render some html table. Finally, invoke some JS. Either from jQuery or from normal JS. Note that I can imagine that some of the Datatables found in Smalltalkhub should have examples. Check them out. Something like this (it's full of domain stuff and probably I am copy pasting with errors but will help you to get the idea): 1) Register lib to app: app addLibrary: DataTablesFileLibrary (or whatever class name is it) 2) Then render table and container (whatever you want, however you want...you simple need a container and a table). containerDiv := html div. containerDivId := containerDiv ensureId. containerDiv class: 'reportContainer'; with: [ html table id: self tableId; with: [ self renderTableOn: html. ]. *html script: (FaDataTablesHelper datatablesScriptFor: tableID tableHeightString: '"scrollY": (0.80 * $(window).height()),' containerDivId: containerDivId). * The magic here is that to the generated table you pass via #script: the Datatables JS. 3) Generate datatables JS: FaDataTablesHelper class >> datatablesScriptFor: tableID tableHeightString: aTableHeightString containerDivId: aContainerDivId ^ ' $(document).ready(function() { var getCellText = function (elem) { //get only the element text return elem.contents().filter(function() { return this.nodeValue; }).text(); }; // this is so that the table does not use all the height space and hence the horizontal scroll looks outside the empty space. // By default, we make the table a max height of a % of the windows. var oTable = $(''#', tableID asString ,''').DataTable( { ', aTableHeightString, ' "scrollX": "100%", "scrollCollapse": true, "paginate": false, "stateSave": false, "stateDuration": -1, "destroy": true, "filter": false, "ordering": false, "searching": false, "sort": false, "orderClasses": false, "autoWidth": false, "jQueryUI": false, // J: ColResize. // I: ColPin. It needs ColReorder. // R: ColReorder // "dom": ''C<"clear">Rt'', "dom": ''t'', // colVis: { // label: function (index, title, th) { // return $(''a[href]'', th).text() || getCellText($(th)); // } // }, // this is in case I want to use the paginate for the Scroller "iDisplayLength": -1 } ); // oTable.colResize.init({fixedLayout: true, dblClick: ''matchContent''}); // Previosuly it was the below line, but this is bad...because if the widths of the columns keep fixed // all along the session, we may wast a lot of space because columns were kepts with its original width... // and when filtering, sorting, etc..the width of the column changes to better adjust its width needs..." // Check if body width is higher than window width :) if ( $(''#', tableID asString ,''').width() > $("#', aContainerDivId,'").width() ) { // Add default fixedColumns // oTable.colPin.init({ // fixedColumns: { // leftColumns: 1, // rightColumns: 1, // heightMatch: ''auto'' // } // }); new $.fn.dataTable.FixedColumns( oTable, { leftColumns: 1, rightColumns: 1 } ); }; //table is bigger than container }); // document on load '. This point 3) depends completely on how you want to use Datatables. Read it's documentation in order to know what you need/want. Also..use the Developer Tools of the browser (console) since you may have missing plugins, or wrong JS code etc. That console will be your friend until you make it work. Cheers, On Sat, Dec 5, 2015 at 11:25 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > I have used this datatable package in Seaside in my app. > > MCSmalltalkhubRepository > owner: 'GastonDallOglio' > project: 'DataTables' > user: '' > password: '' > > For the examples, looking at the Datatables JS API was helpful. The > version was the older one. > > You can use it like this (there is some bootstrap mixed in) > > html tbsTable > beStriped; > beHover; > script: ((html jQuery new dataTable) bFilter: false; bPaginate: false; > bInfo: false); > class: 'table-responsive'; > with: [ > html tableHead with: [ > html tableHeading with: 'ID' seasideTranslated . > html tableHeading with: 'MAC' seasideTranslated . > html tableHeading with: 'IP' seasideTranslated . > html tableHeading with: 'Status' seasideTranslated > ]. > .... > > > > On Sat, Dec 5, 2015 at 9:09 AM, stepharo <stepharo(a)free.fr> wrote: > >> You can use >> - Voyage to access MongoDB read the entreprise Pharo book >> - Garage for relational databases. >> >> http://pharo.org/news/garage-database >> Stef >> >> >> Le 4/12/15 15:58, Pablo R. Digonzelli a Ã©crit : >> >> Hi, I am interesting in using Datatables in a Seaside app. >> I know there is wrapper fot this in StHub. Is there is examples how to >> use it? >> >> >> TIA >> >> ------------------------------ >> *Ing. Pablo Digonzelli* >> Software Solutions >> IP-Solutiones SRL >> Metrotec SRL >> 25 de Mayo 521 >> San Miguel de TucumÃ¡n >> Email: pdigonzelli(a)softsargentina.com >> pdigonzelli(a)gmail.com >> Cel: 5493815982714 >> >> >> > -- Mariano http://marianopeck.wordpress.com

Dec. 8, 2015

Re: [Pharo-users] When a metaclass is initialised by the system ?

by Christophe Demarey

yes, we miss a package initialize method ... Le 8 dÃ©c. 2015 Ã 16:35, Mariano Martinez Peck a Ã©crit : > Dimitris, > > Relying in class side initialize is not very cool. Mostly, because it's hard to know EXACTLY when Monticello will send it. For sure it's the first time you load that class. But then it could be if such method changes again. But maybe too if you clear some Monticello caches... > Also, you may have dependencies (of order execution) with other class side initialize. So...another approaches you can take (depending on your needs) is lazy class var getters with ifNil: or if you have a ConfigurationOfYourApp, you can define #postLoadDoIts in which you can perform the whole initialization of your app. Or ...from the #postLoadDoIts simply delegate to a class MyAppInitialize. > > I do a bit of all of them hahaha. > > Cheers, > > On Mon, Dec 7, 2015 at 9:11 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > ok that means I cannot rely on it and I will have to initialize my class variables in specific methods. No problem, ifNil here I come :) > > On Tue, Dec 8, 2015 at 12:24 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Dimitris, > > > On 07 Dec 2015, at 23:12, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > > > I have read that a metaclass (class side of the class) is initialised when its loaded to the image by monticello, Are there any other cases when the initialize method of the the metaclass is being called ? > > Correct: a class #initialize is called when its code is loaded, but only if it is not yet present or different in source code from what is already present (this last point will bite you one day ;-). > > Else, the #initialize should be called manually (for example to reload some caches, or reset some system state). This sometimes happens in #postLoads or install scripts. > > I am not aware of any automatic invocations. > > Sven > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com

Dec. 8, 2015

Re: [Pharo-users] When a metaclass is initialised by the system ?

by Mariano Martinez Peck

Dimitris, Relying in class side initialize is not very cool. Mostly, because it's hard to know EXACTLY when Monticello will send it. For sure it's the first time you load that class. But then it could be if such method changes again. But maybe too if you clear some Monticello caches... Also, you may have dependencies (of order execution) with other class side initialize. So...another approaches you can take (depending on your needs) is lazy class var getters with ifNil: or if you have a ConfigurationOfYourApp, you can define #postLoadDoIts in which you can perform the whole initialization of your app. Or ...from the #postLoadDoIts simply delegate to a class MyAppInitialize. I do a bit of all of them hahaha. Cheers, On Mon, Dec 7, 2015 at 9:11 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > ok that means I cannot rely on it and I will have to initialize my class > variables in specific methods. No problem, ifNil here I come :) > > On Tue, Dec 8, 2015 at 12:24 AM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> Hi Dimitris, >> >> > On 07 Dec 2015, at 23:12, Dimitris Chloupis <kilon.alios(a)gmail.com> >> wrote: >> > >> > I have read that a metaclass (class side of the class) is initialised >> when its loaded to the image by monticello, Are there any other cases when >> the initialize method of the the metaclass is being called ? >> >> Correct: a class #initialize is called when its code is loaded, but only >> if it is not yet present or different in source code from what is already >> present (this last point will bite you one day ;-). >> >> Else, the #initialize should be called manually (for example to reload >> some caches, or reset some system state). This sometimes happens in >> #postLoads or install scripts. >> >> I am not aware of any automatic invocations. >> >> Sven >> >> >> >> >> -- Mariano http://marianopeck.wordpress.com

Dec. 8, 2015

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

by Mariano Martinez Peck

On Tue, Dec 8, 2015 at 8:11 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Sounds like Marea which never saw the light of day as a part of a Pharo > release/official package. > > http://rmod.inria.fr/web/software/Marea > http://www.jot.fm/issues/issue_2013_01/article2.pdf > > As sometimes happens with research, it ended up with a prototype. Now with a fast become in Spur it would be interesting to give it another pass :) Yes, a subset of Marea. Marea allows you to swap out a given object graph (ideally, unused) to secondary place (files, another image, nosql db, whatever) and let lightweight proxies in the boundary of the graph you swap. If the graph happened to be needed, the proxies take care to bring them all again, materialize, replace proxies with target objects etc until you got back the original graph. Now, it happens that in Smalltalk classes, methods, package etc are all objects graph at the end. That's why I said subset. Because Marea deal with objects graph, whether they are classes/method/packages or domain objects... So yeah, I did an experiment in which I swapped out almost every class/methods of a running seaside image and then I navigated every where in the app so that needed classes that I swapped out would swap it. Then saved the image. Once you saved the image, the image can continue to work perfectly with it's associated secondary memory (files, another image, no sql db...whatever place where you put a fuel BLOB). Guess the image size for such a working/running Seaside app? 4MB. That's give you an idea of the kernel classes really needed to run for example a seaside app :) Best, > On Tue, Dec 8, 2015 at 10:11 AM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> Hi Kilon, >> >> I think what you are describing as a need for you is the ability to >> directly load into an image chunks of image memory space, containing >> already initialized images and code (i.e. live objects stored one way or >> another). Fuel could be an answer to that (wasn't that Tanker, the Fuel for >> code?). >> >> Now, whether those are files or not does not concern me. Give me raw >> blocks on a disk or magic requests to do over a network to get those image >> chunks and I'll be happy. >> >> Thierry >> >> 2015-12-08 1:06 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: >> >>> You could not ask the worst case person even if you wanted :D >>> >>> But here we go ... >>> >>> Will depend , let take my ChronosManager for example >>> >>> To modify the existing code of ChronosManager , is just text that gets >>> compiled to bytecode immediately on each accept, no need to be loaded from >>> a file, even though it gets added to the source and changes files. >>> >>> To add code to the image whether its the entire code of ChronosManager >>> or just a commit, it will load the code from st files, plus the extra >>> filetree metadata files for class definition, version control and method >>> categorization. I use Github but its a very similar story for those using >>> Smalltalkhub. >>> >>> To add code that contains data like an image, like I do with the GUI >>> resources , I use a large collection of PNG files which with the help of >>> the IconFactory will compile the binary data to a bytecode string and also >>> pass it as a form to be used immediately. I am thinking instead to replace >>> the iconfactory with direct access to the png files and creation of the >>> form or a need to exist basis. Lazy loading in short. >>> >>> In the future that I will need a common ground for all the images that >>> use ChronoManager to share data and live state , I will be using fuel >>> files. >>> >>> For Ephestos (ChronosManager is part of the Ephestos project) that has >>> to deal with 3d data, the collection of files grow exponentially which I >>> try to keep outside the image because that data can easily reach several >>> GBs and I dont want the image to explode in my face. To give you an example >>> one folder I have with several blender files is around 2 gbs tops, each >>> file being more than 250 MB. Blend files by the way implement their own >>> kind of "object orientation" even though Blender is largely coded in C. >>> >>> So if you ask me how many files I have to pass to the opal compiler if >>> all I wanted is to stick just with the image my answer would be "a ton" but >>> its a moot a point since the image cant handle so much data anyway. But >>> even in the current scenario, its still a lot of files if you count the >>> pngs and the repository . >>> >>> I actually now try to remove my dependency on SmaCC because it makes the >>> load time very slow, apparently compilation of large projects in the image >>> is super slow and I will divert the parsing back to the python side which >>> is way faster and since its python syntax i am parsing, python is really >>> good at it anyway and helps me remove one unnecessary dependency. Though I >>> have to say I am very happy with SmaCC and its great to have it around. >>> >>> In the future I predict that I will have to keep more and more things >>> into files to make loading of Ephestos fast and also its execution because >>> image is not really optimized for what I want it to use it for. >>> >>> So in my case, its files all the way ! >>> >>> >>> On Tue, Dec 8, 2015 at 1:09 AM Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> Just one simple question... >>>> When you want Pharo to compile some code, which *file* do you pass to >>>> our Opal compiler? >>>> >>>> cheers -ben >>>> >>>> On Tue, Dec 8, 2015 at 2:02 AM, Dimitris Chloupis < >>>> kilon.alios(a)gmail.com> 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(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. >>>> >> >>>> > >>>> >>>> >> > -- Mariano http://marianopeck.wordpress.com

Dec. 8, 2015

Re: [Pharo-users] About GTSpotter matching

by Mariano Martinez Peck

On Tue, Dec 8, 2015 at 5:10 AM, Christophe Demarey < Christophe.Demarey(a)inria.fr> wrote: > Hi, > > By the way, is it possible to have exact match now? > At least, I expect to have expect match on the top of the result list. > +1 > A simple use case, > > - open Spotter > - search number > - dive into implementors category > > > The exact matches are lost in the middle of hundreds of other selectors. > This way, it is very difficult to find what you need. > It is also why I always need to open a playground to be able to search all > implementors of a selector. It is not do-able with spotter without an exact > match. > > Indeed. I do the same. For searching implementors and senders I always have to fallback to old implementors/senders tools. :( > That said, I have to add that I really enjoy spotter and other GT tools :) > > Christophe > > > Le 8 dÃ©c. 2015 Ã 01:56, Juraj Kubelka a Ã©crit : > > > 7. 12. 2015 v 11:59, Peter Uhnak <i.uhnak(a)gmail.com>: > > > On 12/07, Juraj Kubelka wrote: > > Hi, > > > #<anything> is a category filter. Try #class, #instance, etc. > > > Oh... right. I've been using this for long time, my brain just didn't > > connect the dots. > > > In either case, once you dive in the category filter is no longer > > applicable. > > So normally I would do "#i selector", then dive in, and then filter it. > > > Then I have learnt that people are not aware of [...] any other kind of > wild-characters. > > > People don't know what wild-chars are? I would understand that someone > > might be uncomfortable with regexps, because there are many variations, > but wildcharsâ¦ > > > Well, some people asks for regular expressions, some people asks for > wild-characters, some people prefers other techniques. > In most cases people are satisfied with substring solution as it is right > now. In some special cases people thinks about more advance solution. > I believe that we should sort results according to relevance, e.g., if I > write open, then selectors called open should be first, then likely > openOn:, openWithSpec:, openVeryLongExplanation:, etc. > > Cheers, > Juraj > > > > On Dec 5, 2015, at 20:40, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > Hi, > > > are there some wildcards in GTSpotter matching? > > > Currently it searches anywhere in the (method) name, which makes it hard > > for shorter names, because it will match a lot of junk. > > > I've also discovered (by accident), that I can use '>>#selector' to > > anchor the start of the selection. ('#selector' for some reason doesn't > > work). > > But I would like to also search by a simple ? (any character), * (any > > characters) wildcard. Is that possible? > > > Additionally constraining it from the end would be also nice. > > For example I want to look through #default methods, however 90% of the > > matches will be junk, so I would like to write '#default$' and it will > > not match '#defaultIcon', etc. > > > Is this possible? > > > Thanks, > > -- > > Peter > > > > > > -- > > Peter > > > > > > -- Mariano http://marianopeck.wordpress.com

Dec. 8, 2015

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

by Ben Coman

On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > On 12/07, Alejandro Infante wrote: >> 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. > > The complexity should be nlog(n) per iteration. > For such small diagram this should be pretty much instant. > > However from the profiler I can see that a _lot_ of time is spent in > calculating the label size, which definitely shouldn't be this slow... I had this problem with labels a while a go in Rossal 1 when using Unicode in a label. https://github.com/moosetechnology/moose/issues/898 >From memory it came down to calculating the width of a unicode string. I think I hacked it in the rendering loop, such that the string width is cached along with a copy of the string. Next iteration if the string was the same return the cached value, otherwise recalculate. I think I discounted resetting the cache to nil when setting the label string due to inter thread races. cheers -ben > > If you want to look at the other layouts, look at this > https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Layout/0106… > >> >> 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> >> > >> > > -- > Peter >

Dec. 8, 2015

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

by Dimitris Chloupis

whats the diffirence ? On Tue, Dec 8, 2015 at 1:23 PM EuanM <euanmee(a)gmail.com> wrote: > 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" <kilon.alios(a)gmail.com> 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 <horrido.hobbies(a)gmail.com> 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. >>> >>>

Dec. 8, 2015

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

by EuanM

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" <kilon.alios(a)gmail.com> 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 <horrido.hobbies(a)gmail.com> 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. >> >>

Dec. 8, 2015

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

by phil＠highoctane.be

Sounds like Marea which never saw the light of day as a part of a Pharo release/official package. http://rmod.inria.fr/web/software/Marea http://www.jot.fm/issues/issue_2013_01/article2.pdf On Tue, Dec 8, 2015 at 10:11 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi Kilon, > > I think what you are describing as a need for you is the ability to > directly load into an image chunks of image memory space, containing > already initialized images and code (i.e. live objects stored one way or > another). Fuel could be an answer to that (wasn't that Tanker, the Fuel for > code?). > > Now, whether those are files or not does not concern me. Give me raw > blocks on a disk or magic requests to do over a network to get those image > chunks and I'll be happy. > > Thierry > > 2015-12-08 1:06 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > >> You could not ask the worst case person even if you wanted :D >> >> But here we go ... >> >> Will depend , let take my ChronosManager for example >> >> To modify the existing code of ChronosManager , is just text that gets >> compiled to bytecode immediately on each accept, no need to be loaded from >> a file, even though it gets added to the source and changes files. >> >> To add code to the image whether its the entire code of ChronosManager or >> just a commit, it will load the code from st files, plus the extra filetree >> metadata files for class definition, version control and method >> categorization. I use Github but its a very similar story for those using >> Smalltalkhub. >> >> To add code that contains data like an image, like I do with the GUI >> resources , I use a large collection of PNG files which with the help of >> the IconFactory will compile the binary data to a bytecode string and also >> pass it as a form to be used immediately. I am thinking instead to replace >> the iconfactory with direct access to the png files and creation of the >> form or a need to exist basis. Lazy loading in short. >> >> In the future that I will need a common ground for all the images that >> use ChronoManager to share data and live state , I will be using fuel >> files. >> >> For Ephestos (ChronosManager is part of the Ephestos project) that has >> to deal with 3d data, the collection of files grow exponentially which I >> try to keep outside the image because that data can easily reach several >> GBs and I dont want the image to explode in my face. To give you an example >> one folder I have with several blender files is around 2 gbs tops, each >> file being more than 250 MB. Blend files by the way implement their own >> kind of "object orientation" even though Blender is largely coded in C. >> >> So if you ask me how many files I have to pass to the opal compiler if >> all I wanted is to stick just with the image my answer would be "a ton" but >> its a moot a point since the image cant handle so much data anyway. But >> even in the current scenario, its still a lot of files if you count the >> pngs and the repository . >> >> I actually now try to remove my dependency on SmaCC because it makes the >> load time very slow, apparently compilation of large projects in the image >> is super slow and I will divert the parsing back to the python side which >> is way faster and since its python syntax i am parsing, python is really >> good at it anyway and helps me remove one unnecessary dependency. Though I >> have to say I am very happy with SmaCC and its great to have it around. >> >> In the future I predict that I will have to keep more and more things >> into files to make loading of Ephestos fast and also its execution because >> image is not really optimized for what I want it to use it for. >> >> So in my case, its files all the way ! >> >> >> On Tue, Dec 8, 2015 at 1:09 AM Ben Coman <btc(a)openinworld.com> wrote: >> >>> Just one simple question... >>> When you want Pharo to compile some code, which *file* do you pass to >>> our Opal compiler? >>> >>> cheers -ben >>> >>> On Tue, Dec 8, 2015 at 2:02 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> >>> 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(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. 8, 2015

← Newer
1
...
44
45
46
47
48
49
50
...
66
Older →

Jump to page: