February 2015 - Pharo-users

Re: [Pharo-users] Agile visualization book as an interactive grafoscopio document

by Nicolai Hess

Hi Offray, 2015-02-09 22:14 GMT+01:00 Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net> : > Hi all, > .... > So, wiring by "sendToOutside: from:" is not working and I don't know how > to tell my code browser to autosave its contents as part of the node body > where they belong. > > Any help with this is appreciated. > > Cheers, > > Offray > > here is a small example, http://ws.stfx.eu/JBIBBXA0EF3A it uses a memory file system for storing its structure and data. on the left pane, you can select folder and files. And a file will open a code pane on the right side. On this code pane you can edit the text and accept the changes with alt+s (or the icon on the upper right corner). The changed text is saved in the memory file. I use the memory file system just as an example, because I don't have another data structure. But this should work with your GrafoscopioNode too. Does it help? Nicolai

Feb. 10, 2015

Re: [Pharo-users] Nautilus groups

by Luc Fabresse

Hi Christophe, 2015-02-10 14:28 GMT+01:00 Christophe Demarey <christophe.demarey(a)inria.fr>: > Hello, > > We would like to know if some of you use Nautilus groups functionality: > > - dynamic groups: 'Last modified packages', 'Most viewed classes', > 'Work' > > I do not use dynamic groups. > > - user defined groups : from the menu, you can flatten the content of > many packages and get all classes into the newly created group. > > I do not like to flatten > We have the feeling that it is not used (or not a lot) and we think to > replace it with another mechanism (for example, let the user define his/her > 'favorites' classes / packages). > +1 I would prefer to be able to save a regular expression (the one I enter in the text area above Package list) Cheers, #Luc > > Thanks for the feedback. > >

Feb. 10, 2015

Re: [Pharo-users] PhD offer with Pharo about Interaction design

by Camille

Great! > On 10 Feb 2015, at 14:29, stepharo <stepharo(a)free.fr> wrote: > > > http://www.inria.fr/en/institute/recruitment/offers/phd/campaign-2015/%28vi… > >

Feb. 10, 2015

PhD offer with Pharo about Interaction design

by stepharo

http://www.inria.fr/en/institute/recruitment/offers/phd/campaign-2015/%28vi…

Feb. 10, 2015

Nautilus groups

by Christophe Demarey

Hello, We would like to know if some of you use Nautilus groups functionality: dynamic groups: 'Last modified packages', 'Most viewed classes', 'Work' user defined groups : from the menu, you can flatten the content of many packages and get all classes into the newly created group. We have the feeling that it is not used (or not a lot) and we think to replace it with another mechanism (for example, let the user define his/her 'favorites' classes / packages). Thanks for the feedback.

Feb. 10, 2015

Changes file size

by Torsten Bergmann

>I always found it strange what effect loading Glorp had on an image, blowing it up. Looks like it is really an effect of the Glorp code. Maybe because it was initially exported from VW and then imported into Squeak/Pharo. I always thought slow loading is because of this or the long license texts in the classes. At least I had similar issues when I loaded the "Glorp-EstebanMaringolo.92" from October 2014. I was not able to browse diffs, etc. when I wanted to clean up. Then I commited "Glorp-TorstenBergmann.93" without real changes and things started to stabilize. At least I was able to browse the diffs afterwards and could refactor a little bit with Glorp-TorstenBergmann.94. Bye T.

Feb. 10, 2015

Re: [Pharo-users] Changes file size

by Sven Van Caekenberghe

Esteban, You might be on something important there. I always found it strange what effect loading Glorp had on an image, blowing it up. I can't say I understand though, best make it into an issue. Sven > On 10 Feb 2015, at 00:22, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > Just when I found a way to reduce the total size of the changes file, I > noticed the latest versions in the repository doesn't have this issue, > what a good way of wasting one's time learning about the guts of > Monticello :) > > But just for the record: > The problem happened after installing into GlorpSession a > MCMethodDefinition (#dropTables:), I logged every single method > installation, and the point where things went bananas was after > installing that culprit method: > > After a MCMethodDefinition(dropTables): 1201686 bytes (~1.2Mb) > After a MCMethodDefinition(dropTables:): 135419895 bytes (~135Mb) > > I did a fileOut, deleted the method, and then file it in again, and > after versioning (and reloading) the changes increased ~1Mb after > installing Glorp. > > I didn't find anything particularly suspicious about it, not in the > source code nor in the bytecodes. > > Now after running PharoChangesCondenser condense the changes file > effectively shrinks. > > Regards! > > > Esteban A. Maringolo > > > 2014-10-28 12:31 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> >>> On 28 Oct 2014, at 14:58, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>> >>> 2014-10-28 5:41 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>>> Esteban, >>>> >>>> The Reddit example's CI Job (https://ci.inria.fr/pharo-contribution/job/Reddit/) also loads Seaside and Glorp (two big packages) in Pharo 3 and it too results in a 110 Mb image and 142 Mb changes file. After condensing, that goes to 276 Mb ! >>> >>>> I would say something is wrong here ;-) >>> >>> Either something is wrong, or we feature it and rename >>> PharoChangesCondenser>>#condense to PharoChangesExpander>>#expand :) >>> >>>> Note that condensing changes on newly loaded code should not make much difference (in essence, all multiple versions of methods are reduced to 1). >>> >>>> I think we should create some issues out of this. >>> >>> This is true, however I find a changes of 140 megs to be MASSIVE. >> >> I totally agree, this is unacceptable. However, I did some tests, and the problem is with Glorp (or any of its sub packages). I tried building both my Reddit and HP35 examples from scratch in Pharo 3 on Linux. >> >> $ ./pharo reddit.image config http://smalltalkhub.com/mc/SvenVanCaekenberghe/Reddit/main ConfigurationOfReddit --install=stable >> >> $ ./pharo hp35.image config http://smalltalkhub.com/mc/SvenVanCaekenberghe/HP35/main ConfigurationOfHP35 --install=stable --group=Web-UI >> >> Both load Seaside and some other stuff, but only Reddit loads Glorp and PostgresV2. >> >> I did a condense changes on the HP35 image, the one on the Reddit image ran out of physical memory (granted is was a small machine) ! >> >> Here are the resulting sizes: >> >> $ ls -lah >> total 337M >> drwxr-xr-x 4 root root 4.0K Oct 28 15:09 . >> drwx------ 12 root root 4.0K Oct 28 12:28 .. >> -rw-r--r-- 1 root root 5.8M Oct 28 13:17 hp35.changes >> -rw-r--r-- 1 root root 5.6M Oct 28 14:38 hp35-condense-test.changes >> -rw-r--r-- 1 root root 5.8M Oct 28 14:27 hp35-condense-test.changes.bak >> -rw-r--r-- 1 root root 29M Oct 28 14:38 hp35-condense-test.image >> -rw-r--r-- 1 root root 29M Oct 28 13:17 hp35.image >> drwxr-xr-x 2 root root 4.0K Oct 28 13:12 package-cache >> -rwxr-xr-x 1 root root 367 Oct 28 12:29 pharo >> -rw-rw-r-- 1 root root 265K Oct 24 14:42 Pharo.changes >> -rw-rw-r-- 1 root root 21M Oct 24 14:42 Pharo.image >> -rwxr-xr-x 1 root root 354 Oct 28 12:29 pharo-ui >> drwxr-xr-x 3 root root 4.0K Oct 28 12:29 pharo-vm >> -rw-r--r-- 1 root root 136M Oct 28 12:48 reddit.changes >> -rw-r--r-- 1 root root 105M Oct 28 12:48 reddit.image >> >> Note how the HP35 image and changes sizes are totally acceptable/normal, while the Reddit one explodes, with the difference being Glorp. >> >> But I have no idea what causes this. >> >> There is no way Glorp can generate 100 Mb changes, when Seaside is OK with 6 Mb. >> >>> I remember loading ~4000 classes in the order of 10^6 LOC in Dolphin, and >>> changes never got half that size. Sizes were ~28/55MB image/changes. >>> The same in VAST, any image beyond the 20MB was an alert of something >>> being leaked. >>> >>>> Hmm, we need more tests and data points, I will try on Linux command line later on. >>> >>> I ran in it in Linux (Ubuntu) through the command line. >>> >>> >>> Regards! >>> >> >> >

Feb. 10, 2015

Re: [Pharo-users] Spotter vs Spotlight was: [Re: Cleaning code completition's namespace]

by Tudor Girba

Hi Laura, Thanks for the detailed answer. Please let's continue this discussion. It will help us figure out how to describe Spotter and maybe it will provide . On Sun, Feb 8, 2015 at 6:27 PM, Laura Risani <laura.risani(a)gmail.com> wrote: > Hi again Doru , > > Thanks for the detail feedback. I provided some inlined answers and took >> the liberty of changing the thread subject. >> >> > It was just a first impression, perhaps once i get to properly know the > tool and give it the proper trial period it deserves (as a work someone put > dedication on and also as something many knowledgeable people have chosen), > i could articulate a more funded opinion. > Sure. About the thread subject, my intent was to compare both tools just from the > perspective of the the need i stated "quickly find and/or browse classes > and msg implementations/senders", and argument why for that need i would > choose Spotlight, to me they are not comparable from any other perspective. > Ok. > As you state below the purpose of Spotter is "provide a uniform interface > to search all sorts of objects that you see interesting", so to me it > doesn't seems to rival Spotlight but Finder. > Both. And it starts to also overlap the MessageBrowser and the FileBrowser. > As mentioned, please try with the latest Pharo. I just tried 40481. The >> problem is fixed. >> > > Dark theme works fine, looks nicer now! > > Spotter is not a tool for accessing menus :). It simply also offers a way >> to access menus. >> > > I wanted to mean that i wouldn't use it instead of world menu, to the end > of navigating world menu. Yet it would be an (afaik) innovation if it could > search inside all existing menus in the image, and i would use it for that > end. > What do you mean about all existing menus in the image? Right now, the default Spotter searches for the top level entries in the World menu and then lets you dive if you want. It can also be made easily to search for all menu entries from the World menu. Is that what you have in mind? > This implies that all you want to do is look for a class or for a message. >> What about a pragma? Or a package? Or a previous script that you used in >> the Playground? Or global variables? Or a method inside a class? These >> deserve a way to be found as well, and Spotter is an interface for >> searching objects. >> >> > Perhaps i wasn't clear enough in my expression. As i said before i wanted > to compare just from the perspective of the before mentioned need. > I do need to look for all that sort of things, but i have other tools for > those, > package, method inside a class -> Class Browser > pragma, globals -> Finder > previous script -> don't know any nice tool. > Yet i would use other tools if they offered usability improvements. > >> >> >>> In contrast, from the perspective of that need, Spotter >>> -Doesn't search "names" (class names/selectors) but implementations, >>> overlaping the two actions of the need (when i olny hava a clue and i'm not >>> sure of the name i'm interesed into, i don't care for the list of >>> implementations, is obstrusive "garbage"). Forcing me to unnecessarily >>> think how to do what i want to do. In addition i find it hard to think >>> about the tool because i can't figure out a statement of purpose for it, >>> perhaps "global search for a name", but i'm not sure of "global" because it >>> doesn't do source code. >>> >> -Shows me "garbage" i have to mentally filter (world menu, packages, >>> pragmas, ... ). >>> >> >> I think you are misinterpreting the goal of Spotter. It is meant to >> provide a uniform interface to search all sorts of objects that you see >> interesting, and it even offers a cheap way to tweak its behavior to your >> needs. Here is a post that describes it in more details: >> http://www.humane-assessment.com/blog/introducing-gtspotter/ >> > > It states > "Until now, the way to search for implementors in Pharo is to open a > Playground, enter a the symbol, press *Cmd+m* and then close the > Playground window." > I don't know if this post is previous to the v3 release i have that comes > with Spotlight and a shortcut for it on ToolShortcuts>>openSpotlight > Yes, Spotlight is a way to do that too. And it is indeed better than the Playground solution. Still I saw all the time people using Playground for that purpose. Since i'm dark-theme keyword-only minded i stand applaud this feature > "The interface is fully controllable through the keyboard. " > > Also found these ones to be useful innovations > "Spotting past Playground pages" > "Spotting the last spotted objects" > > Then the possibility of navigating through related objects of the system > in just one window, it is a quite valuable one. To me it resolves with the > addition of an optional modifying key to the existing pervading browse > shortcuts (senders, implementations, class ...) to address the two equally > useful actions of opening a new window and keep open or close current one . > > About "provide a uniform interface to search all sorts of objects that you > see interesting". > Do you mean graphic interface, right? > Both graphical and conceptual. I ingenuously pose the question Why is better a uniform GUI for searching? > I'm not sure whether the question subject's nature is objective and then > we could find an answer or whether it is subjective an all we can get is a > set of opinions. > I'm not sure what "uniform" mean... is "uniform" as opposed to > "specialized"? Doesn't a specialized search result interface, where the > searched thing's qualities are known beforehand, let you leverage that > context to provide a richer and more efficient interface? > In this mail alone you list 4 different search tools: Finder, MessageBrowser, Spotlight, Search in Nautilus. Each of these behaves radically different without much of an added value. The whole philosophy of Smalltalk revolves around a minimal and uniform model that can be used to express elegantly any action. For example, Smalltalk has a simple syntax, and yet you can explain with that simple syntax all things for which other languages require lots of hardcoded constructs. The same rigor should be applied to the user interface. With Spotter we strive to reach such a simple model that can be infinitely moldable to fit custom needs. Now, besides elegance, if any, what else is there? Given that search is such a pervasive action, before I start anything I first want to find an entry point. That can be a method, a class, a file, or whatever other object. To this end, first people think of what tool to use and then of how to find the interesting object inside that tool. With Spotter we want to eliminate the first step: we just open Spotter and start searching for what we want. It's not quite there, but I think it is amazingly close to this goal. To summarize my issues with the GUI are > 1) As a keybordian one of my main concerns is keystroke cost of an action, > MessageBrowser shows me by default the two pane views (results and method > code) cause it is implicit it's dealing with msgs, but in Spotter i have to > press a keycombination to bring up the code pane. > Opening a preview is a sticky behavior: once opened/closed, it stays like that for subsequent usages. > 2) Not having the regular features of a window that are useful depending > on the case, for shortcuting i would like volatile but for browsing results > i could depending on the case prefer persistency . > Certainly. The current solution focuses on search. Creating a persistent list of objects is still a work in progress but it is out of scope at the moment. > Also when i open a window its because my highest priority interest is its > content (if not i tile), so i like my windows to open as bigger as they can > (yet to get this behavior requires me to do very little code modifications). > I do not understand this one. Could you elaborate? 3) Main concern is that i can't tell at a glance the purpose and > comprehensive features of the tool, an explanation is required. In contrast > Finder gives me a list on top row of things that it can find, so it is > clear at a glance that it searches narrowed one of those things. > > For a tool that "searches all sorts of objects" an ideal GUI to me would be > 1)"What to search for" . A two key shortcut that opens a kind of somehow > logical structured list/table of the names of the types of objects one > could search, this window would be "as bigger as possible" and volatile. > ( > for example > "definitions" : class, methods, variables, pragmas > interfaces: world menu, all menus > code: playgrounds, source > metadata: .... > complex/custom queries: ... > image: ...?... > .... > ) > There will be a hint of the search input box that will list all searchable categories for the current object. Keep in mind that because we have diving possibility, every object can define what can be interesting to search. So, there isn't a single list of categories but there are many lists. For example, right now, there are some 59 such extensions in the image. To find them, you can search for the spotterOrder: pragma, dive in, and then you will see all methods that references this pragma. > 2) "Search for it". Each of those names would have a letter underlined and > when you press just that letter key a specialized search interface narrowed > to that type would show > ( > for example > classes would show their packages > methods all MessageBrowser info > ) > these windows would be regular and one could choose by pressing a > modifying key when opening them to make them volatile or not. > This already works. As explained before, something like: d #i will give you only the implementors of "d". So, # will search for the name of the category. This feature is not yet complete in that it does not highlight properly the results, but could you try to see if this fits what you have in mind? I want to stress one more time that this is my personal opinion for myself, >>> and while i probably won't use the tool >>> >> >> I think you will :). >> > > I will give it a try with the added method for sure! > With current Spotter's interface i probably keep Spotlight for shortcut > access and Spotter+Finder for finding. > If the interface was changed to my ideal one, i would use it without > hesitation. > If not but if i found Spotter functionalities to be innovations of great > value then i'd try myself to modify the interface to make it as close as my > ideal and use Spotter. > Did you try compiling the method that I sent in the previous mail (basically just copy paste that method in the GTSpotter class)? It should provide the behavior of Spotlight. Please try and let me know if it works for you. Cheers, Doru > >> i think that Spotlight and Spotter should coexist as other tools do >>> (like Workspace and Playground) because one tool can't fit all >>> mindsets/preferences. >>> >> >> Sure. But, what makes you say they do not coexist (I did not see this >> argument above)? >> > > I misexpressed. I wanted to point out that Spotlight comes no longer in > the distribution, the could both come in it, as tools like Workspace and > GTPlayground, and many themes. Yet each one can load the packages he likes > the most. > An applause for Spotter's intent to push the current boundaries of > usability! > > Love, > Laura > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 10, 2015

Re: [Pharo-users] [Moose-dev] Agile visualization book as an interactive grafoscopio document

by Alexandre Bergel

Hi Offray, If I correctly understand your question you want to auto save something in your glamour script. I do not know since I am not expert in Glamour. But I think glamour emit some event and you can have some callbacks for this. I saw this while browsing the glamour examples. Cheers, Alexandre > Le 9 fÃ©vr. 2015 Ã 18:14, Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net> a Ã©crit : > > Hi all, > > This mail will have two parts, a small first one where I share my advances and little context on the project and the second one, with details where I made specific questions regarding concepts and code and how to make progress. I hope to be fluid and proper balanced and interesting enough to get feedback soon. > > Context > ======= > > I have made a small video at [1] showing my progress on Grafoscopio[2], a tool for the creation of interactive notebooks for open/citizen/garage science and research (for a better view I recommend to see the video in full screen mode). > > As you can see, I have a complete outline of the Agile Visualization book stored as a single "ston document" [3], that can be exported to pandoc's markdown [4] and from there to LaTeX, pdf, html, doc, etc. > It can contain special tagged nodes and the view and behaviour of them change accordingly to the tag. In the video a node tagged as code is showed as an interactive playground where you can execute an explore the objects deeper. > > My problem is that this kind of special nodes are not saved, as happens with default nodes and the reason is that the special view (which is a sub-browser) is not wired properly to the rest of the browser and that's why I get a nill value after revisiting the code node in the video. > > > [1] https://archive.org/details/gfcp-alpha-code-exec-but-non-saving.mp4 > > [2] http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-ini… > > [3] http://mutabit.com/deltas/repos.fossil/grafoscopio/doc/tip/Docs/En/Books/Ag… > > [4] http://mutabit.com/deltas/repos.fossil/grafoscopio/doc/tip/Docs/En/Books/Ag… > > > Details > ======= > > The logic of what I'm doing is something like this: > > i. When a node in tree at the left is selected, it shows the contents of the selected tree. > > ii. If something changes in the node content at the right, the changes are automatically updated. > > iii. If a node is tagged in a special way, a custom browser is called. > > The code that select which sub-browser to show for a particular tagged node is something like this: > > ==[a]============================== > UI>>buildBrowserNamed: aName > "Main method for building the interface for trees and its nodes. The name of the browser corresponds to the name of the file > where tree is stored (or is named 'draft.ston' by default)" > > "... snip" > > (browser transmit) > from: #tree port: #selection; > to: #nodeBody; > when: [:selection | selection notNil]; > andShow: [ :a :node | > self bodyIn: a for: node. > self body2ForCodeIn: a for: node. > self bodyForTransmediaIn: a for: node ]. > "... snip" > > "Creating a self updatable body pane" > (browser transmit) > from: #tree port: #selection; > to: #nodeBody; > when: [:selection | selection notNil]; > andShow: [ :a :node | > self bodyIn: a for: node. > self body2ForCodeIn: a for: node. > self bodyForTransmediaIn: a for: node ]. > (browser transmit ) > from: #tree port: #selection; > from: #nodeBody port: #text; > when: [:node :text | text notNil & node notNil]; > to: #nodeBody port: #neverland; > transformed: [:node :text | node body: text asString]. > (browser transmit) > from: #tree; > to: #nodeHeader; > andShow: [ :h | self headerOn: h ]. > (browser transmit ) > from: #tree port: #selection; > from: #nodeHeader port: #text; > to: #nodeHeader port: #neverland1; > when: [:node :text | text notNil & node notNil]; > transformed: [:node :text | node header: text asString] > > =================================== > > The last part of the code is responsible for updating the tree contents automatically with > > The "body2ForCodeIn: for:" [b] is the responsible for showing the playground by calling a custom browser that is called "panelAsCodeFor:"[c]. Here is their code: > > > ==[b]============================== > UI>> body2ForCodeIn: constructor for: aNode > "Shows the body of a selected node as executable code." > > aNode tags = 'cÃ³digo' > ifFalse: [ ^self ] > ifTrue: [constructor custom: (self panelAsCodeFor: aNode)]. > =================================== > > > ==[c]============================== > panelAsCodeFor: aNode > "Shows an interactive playground for Smalltalk code in a node body" > > browser := GLMTabulator new. > browser title: 'CÃ³digo'. > browser column: #code. > browser transmit > to: #code; > transformed: [ GTPlayPage new content: aNode body ]; > andShow: [ :a | a custom: GTPlayground new ]. > browser sendToOutside: #nodeBody from: #code -> #text. > ^ browser. > =================================== > > So, wiring by "sendToOutside: from:" is not working and I don't know how to tell my code browser to autosave its contents as part of the node body where they belong. > > Any help with this is appreciated. > > Cheers, > > Offray > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Feb. 9, 2015

Re: [Pharo-users] Changes file size

by Esteban A. Maringolo

Just when I found a way to reduce the total size of the changes file, I noticed the latest versions in the repository doesn't have this issue, what a good way of wasting one's time learning about the guts of Monticello :) But just for the record: The problem happened after installing into GlorpSession a MCMethodDefinition (#dropTables:), I logged every single method installation, and the point where things went bananas was after installing that culprit method: After a MCMethodDefinition(dropTables): 1201686 bytes (~1.2Mb) After a MCMethodDefinition(dropTables:): 135419895 bytes (~135Mb) I did a fileOut, deleted the method, and then file it in again, and after versioning (and reloading) the changes increased ~1Mb after installing Glorp. I didn't find anything particularly suspicious about it, not in the source code nor in the bytecodes. Now after running PharoChangesCondenser condense the changes file effectively shrinks. Regards! Esteban A. Maringolo 2014-10-28 12:31 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > >> On 28 Oct 2014, at 14:58, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >> 2014-10-28 5:41 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> Esteban, >>> >>> The Reddit example's CI Job (https://ci.inria.fr/pharo-contribution/job/Reddit/) also loads Seaside and Glorp (two big packages) in Pharo 3 and it too results in a 110 Mb image and 142 Mb changes file. After condensing, that goes to 276 Mb ! >> >>> I would say something is wrong here ;-) >> >> Either something is wrong, or we feature it and rename >> PharoChangesCondenser>>#condense to PharoChangesExpander>>#expand :) >> >>> Note that condensing changes on newly loaded code should not make much difference (in essence, all multiple versions of methods are reduced to 1). >> >>> I think we should create some issues out of this. >> >> This is true, however I find a changes of 140 megs to be MASSIVE. > > I totally agree, this is unacceptable. However, I did some tests, and the problem is with Glorp (or any of its sub packages). I tried building both my Reddit and HP35 examples from scratch in Pharo 3 on Linux. > > $ ./pharo reddit.image config http://smalltalkhub.com/mc/SvenVanCaekenberghe/Reddit/main ConfigurationOfReddit --install=stable > > $ ./pharo hp35.image config http://smalltalkhub.com/mc/SvenVanCaekenberghe/HP35/main ConfigurationOfHP35 --install=stable --group=Web-UI > > Both load Seaside and some other stuff, but only Reddit loads Glorp and PostgresV2. > > I did a condense changes on the HP35 image, the one on the Reddit image ran out of physical memory (granted is was a small machine) ! > > Here are the resulting sizes: > > $ ls -lah > total 337M > drwxr-xr-x 4 root root 4.0K Oct 28 15:09 . > drwx------ 12 root root 4.0K Oct 28 12:28 .. > -rw-r--r-- 1 root root 5.8M Oct 28 13:17 hp35.changes > -rw-r--r-- 1 root root 5.6M Oct 28 14:38 hp35-condense-test.changes > -rw-r--r-- 1 root root 5.8M Oct 28 14:27 hp35-condense-test.changes.bak > -rw-r--r-- 1 root root 29M Oct 28 14:38 hp35-condense-test.image > -rw-r--r-- 1 root root 29M Oct 28 13:17 hp35.image > drwxr-xr-x 2 root root 4.0K Oct 28 13:12 package-cache > -rwxr-xr-x 1 root root 367 Oct 28 12:29 pharo > -rw-rw-r-- 1 root root 265K Oct 24 14:42 Pharo.changes > -rw-rw-r-- 1 root root 21M Oct 24 14:42 Pharo.image > -rwxr-xr-x 1 root root 354 Oct 28 12:29 pharo-ui > drwxr-xr-x 3 root root 4.0K Oct 28 12:29 pharo-vm > -rw-r--r-- 1 root root 136M Oct 28 12:48 reddit.changes > -rw-r--r-- 1 root root 105M Oct 28 12:48 reddit.image > > Note how the HP35 image and changes sizes are totally acceptable/normal, while the Reddit one explodes, with the difference being Glorp. > > But I have no idea what causes this. > > There is no way Glorp can generate 100 Mb changes, when Seaside is OK with 6 Mb. > >> I remember loading ~4000 classes in the order of 10^6 LOC in Dolphin, and >> changes never got half that size. Sizes were ~28/55MB image/changes. >> The same in VAST, any image beyond the 20MB was an alert of something >> being leaked. >> >>> Hmm, we need more tests and data points, I will try on Linux command line later on. >> >> I ran in it in Linux (Ubuntu) through the command line. >> >> >> Regards! >> > >

Feb. 9, 2015