June 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] How to deploy headless app without changes and source files?

by Sven Van Caekenberghe

You could also subclass PharoFilesOpener with NoPharoFilesOpener, override #sourcesFileOrNil and #changesFileOrNil to just return nil, and #install it as Default. And hope that the callers can deal with the nils. > On 7 Jun 2017, at 09:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Andreas, > > What if you subclassed ChangesLog, say with something called NoChangesLog and installed that as its DefaultInstance (as accessed by #default), with an #install class side message. > > Then override #logChange: and #logSnapshot:andQuit: to do nothing. > > No need to subscribe to system announcements. > > To install, you do > > NoChangesLog install. > > To get back, you do > > ChangesLog reset. > > I think that could/would work (the code in System-Sources was refactored quite well). > > HTH, > > Sven > >> On 7 Jun 2017, at 04:19, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: >> >> For now, in my 'deployed' image, I have: >> 1. Disabled SourceFilesArray >> forceChangesToDisk >> I did not find any code branch that would avoid this, so for now I just made it do nothing. Maybe I should disable ChangesLog >> logChange: instead. >> >> 2. Disabled PharoFilesOpener >> changesFileOrNil >> Same story. But this only causes warning get printed out, not error. Disabling it removes the warning message. >> >> 3. Set changesFileStream to nil (SourceFiles changesFileStream: nil). >> Some code does have guard against nil value for this changes stream. >> >> This works for me if I do not have the changes file with the image. If I have the changes file and it's read-only, that's a different problem. >> >> It seems that this was possible before, judging from the older links I found in my original email and the existence of some guards against non-existence changes file. >> >> I'll check those links and perhaps see if I can be helpful there, but I right now have delivery to make. And I can't wait to try Pharo 6 too. >> >> -- >> Andreas >> >> >> On Tue, Jun 6, 2017 at 6:37 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> On Wed, Jun 7, 2017 at 3:23 AM, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: >> Hi Stef, >> >> I can't have changes file bundled with the tool because the tool is installed in a centralized location in my network and multiple users will run it. So the image is in a central location and read-only and so is the changes file (if I must have a changes file). The tool is only a processor. It does not need to keep/save its state. >> >> Hence, I cannot have multiple users writing to that one and the same changes file. >> >> I'm trying to dissect the call chain to ChangesLog and try to cut it so Pharo won't write to the changes file. I'm sure I should not do this. There must be a better way. >> >> I guess this use case just hasn't been critical for other people (there are lots of competing priorities) and they've found ways of working around it, like making your network located tool a script that copies itself itself to a use folder and run from there. But of course it would be better for Pharo to work cleanly without a changes file. To make it better, someone has to do it, so feel free to propose some code changes (with discussion of such on pharo-dev list). >> >> Here is one hint (something related I worked on recently)... >> https://pharo.fogbugz.com/f/cases/20074/Red-pane-of-death-when-sources-file… >> To view the changes, open image 60494 (easiest using PharoLauncher) >> and load the slice. >> >> Filtering the issue tracker on "changes file" pops up a few other possibilities (I haven't reviewed them, and you might find others) >> https://pharo.fogbugz.com/f/cases/11204/Crash-if-changes-file-is-not-writab… >> https://pharo.fogbugz.com/f/cases/11426/Extract-the-logic-that-opens-the-so… >> >> cheers -ben >> >> >> >> On Tue, Jun 6, 2017 at 11:55 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> We started to work on making the system ready to stop using these files. >> There are two things. >> - the changes are a tape that logs what you are doing and right now >> the system is not done to accept not to log >> So I imagine that you can remove the changes file but then do not compile code. >> - I do not get the "so I can't have changes file bundled with the tool." >> you do not have a bat or script that launches the application that is >> somewhere in a folder where you have the vm and the image? you could >> have the changes file there. >> >> We are interested in your scenario because last year I got a guy >> working on making pharo silent. I do not know if its changes got >> integrated into pharo. >> This is really something that we want to have. >> - having sources and changes in a specific location >> - having no source and no changes (even if it means lose your code). >> - ... >> >> Stef >> >> On Tue, Jun 6, 2017 at 8:14 PM, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: >>> Sorry to bring this up again. But it turns out that I had the image >>> directory writable by myself, so it created a new changes file. That's why >>> Pharo didn't complain about missing changes file. When I removed write >>> permission in the tool installation, Pharo gives error for not having or not >>> able to write to changes file. >>> >>> I guess I'm back to the problem how to deploy a tool without changes file. I >>> have multiple users that will be running this tool, which is installed in a >>> centralized site, so I can't have changes file bundled with the tool. >>> >>> On Mon, Jun 5, 2017 at 5:47 PM, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: >>>> >>>> I had my changes and sources files in the bundle but has their write >>>> permission removed, and that causes the error. Simply deploying the tool >>>> without the changes file seems to fix it. Pharo5 doesn't complain if the >>>> changes file isn't there. >>>> >>>> However, without the sources file, I get this warning that pharo cannot >>>> locate the sources file. Including the sources file in the deployed tool is >>>> fine with me. >>>> >>>> So, I think that's my solution. Thanks! >>>> >>>> >>>> On Mon, Jun 5, 2017 at 5:07 PM, Andreas Sunardi <a.sunardi(a)gmail.com> >>>> wrote: >>>>> >>>>> I found this StackOverflow question: >>>>> >>>>> https://stackoverflow.com/questions/14737695/is-it-possible-to-deploy-a-pha… >>>>> >>>>> and this older forum thread: >>>>> >>>>> https://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg21170.h… >>>>> >>>>> I'm using Pharo5.0 and neither of these options is available anymore. >>>>> What is the new way to do this? >>>>> >>>>> -- >>>>> Andreas Sunardi >>>> >>>> >>> >> >> >> >> >

June 7, 2017

Re: [Pharo-users] How to deploy headless app without changes and source files?

by Sven Van Caekenberghe

Andreas, What if you subclassed ChangesLog, say with something called NoChangesLog and installed that as its DefaultInstance (as accessed by #default), with an #install class side message. Then override #logChange: and #logSnapshot:andQuit: to do nothing. No need to subscribe to system announcements. To install, you do NoChangesLog install. To get back, you do ChangesLog reset. I think that could/would work (the code in System-Sources was refactored quite well). HTH, Sven > On 7 Jun 2017, at 04:19, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: > > For now, in my 'deployed' image, I have: > 1. Disabled SourceFilesArray >> forceChangesToDisk > I did not find any code branch that would avoid this, so for now I just made it do nothing. Maybe I should disable ChangesLog >> logChange: instead. > > 2. Disabled PharoFilesOpener >> changesFileOrNil > Same story. But this only causes warning get printed out, not error. Disabling it removes the warning message. > > 3. Set changesFileStream to nil (SourceFiles changesFileStream: nil). > Some code does have guard against nil value for this changes stream. > > This works for me if I do not have the changes file with the image. If I have the changes file and it's read-only, that's a different problem. > > It seems that this was possible before, judging from the older links I found in my original email and the existence of some guards against non-existence changes file. > > I'll check those links and perhaps see if I can be helpful there, but I right now have delivery to make. And I can't wait to try Pharo 6 too. > > -- > Andreas > > > On Tue, Jun 6, 2017 at 6:37 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Wed, Jun 7, 2017 at 3:23 AM, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: > Hi Stef, > > I can't have changes file bundled with the tool because the tool is installed in a centralized location in my network and multiple users will run it. So the image is in a central location and read-only and so is the changes file (if I must have a changes file). The tool is only a processor. It does not need to keep/save its state. > > Hence, I cannot have multiple users writing to that one and the same changes file. > > I'm trying to dissect the call chain to ChangesLog and try to cut it so Pharo won't write to the changes file. I'm sure I should not do this. There must be a better way. > > I guess this use case just hasn't been critical for other people (there are lots of competing priorities) and they've found ways of working around it, like making your network located tool a script that copies itself itself to a use folder and run from there. But of course it would be better for Pharo to work cleanly without a changes file. To make it better, someone has to do it, so feel free to propose some code changes (with discussion of such on pharo-dev list). > > Here is one hint (something related I worked on recently)... > https://pharo.fogbugz.com/f/cases/20074/Red-pane-of-death-when-sources-file… > To view the changes, open image 60494 (easiest using PharoLauncher) > and load the slice. > > Filtering the issue tracker on "changes file" pops up a few other possibilities (I haven't reviewed them, and you might find others) > https://pharo.fogbugz.com/f/cases/11204/Crash-if-changes-file-is-not-writab… > https://pharo.fogbugz.com/f/cases/11426/Extract-the-logic-that-opens-the-so… > > cheers -ben > > > > On Tue, Jun 6, 2017 at 11:55 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > We started to work on making the system ready to stop using these files. > There are two things. > - the changes are a tape that logs what you are doing and right now > the system is not done to accept not to log > So I imagine that you can remove the changes file but then do not compile code. > - I do not get the "so I can't have changes file bundled with the tool." > you do not have a bat or script that launches the application that is > somewhere in a folder where you have the vm and the image? you could > have the changes file there. > > We are interested in your scenario because last year I got a guy > working on making pharo silent. I do not know if its changes got > integrated into pharo. > This is really something that we want to have. > - having sources and changes in a specific location > - having no source and no changes (even if it means lose your code). > - ... > > Stef > > On Tue, Jun 6, 2017 at 8:14 PM, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: > > Sorry to bring this up again. But it turns out that I had the image > > directory writable by myself, so it created a new changes file. That's why > > Pharo didn't complain about missing changes file. When I removed write > > permission in the tool installation, Pharo gives error for not having or not > > able to write to changes file. > > > > I guess I'm back to the problem how to deploy a tool without changes file. I > > have multiple users that will be running this tool, which is installed in a > > centralized site, so I can't have changes file bundled with the tool. > > > > On Mon, Jun 5, 2017 at 5:47 PM, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: > >> > >> I had my changes and sources files in the bundle but has their write > >> permission removed, and that causes the error. Simply deploying the tool > >> without the changes file seems to fix it. Pharo5 doesn't complain if the > >> changes file isn't there. > >> > >> However, without the sources file, I get this warning that pharo cannot > >> locate the sources file. Including the sources file in the deployed tool is > >> fine with me. > >> > >> So, I think that's my solution. Thanks! > >> > >> > >> On Mon, Jun 5, 2017 at 5:07 PM, Andreas Sunardi <a.sunardi(a)gmail.com> > >> wrote: > >>> > >>> I found this StackOverflow question: > >>> > >>> https://stackoverflow.com/questions/14737695/is-it-possible-to-deploy-a-pha… > >>> > >>> and this older forum thread: > >>> > >>> https://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg21170.h… > >>> > >>> I'm using Pharo5.0 and neither of these options is available anymore. > >>> What is the new way to do this? > >>> > >>> -- > >>> Andreas Sunardi > >> > >> > > > > > >

June 7, 2017

Re: [Pharo-users] [ANN] Pharo 6.0 released!

by Alistair Grant

Great news! Thanks to Esteban and the 80+ contributors. I have multiple patches waiting for the 7.0 dev cycle to begin. Can't wait... :-) Cheers, Alistair On 6 June 2017 at 17:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Dear World, > > The time has come for Pharo 6.0! > > Pharo is a pure object-oriented programming language and a powerful > environment, focused on simplicity and immediate feedback. > > This is our most significant release yet. Here are some highlights: > > - Pharo is now provided in 64-bit version in Linux and OSX and brings even > better performance and stability (beware, 64bits version is a new technology > and a small amount of tests is still failing) > - A new code changes management system named Epicea for easier reviewing and > recovering of your code easily > - Integrated support for Git through an easy-to-use tool for repositories > and commits management named Iceberg (as a preview for Pharo 6, it will be > the default in Pharo 7) > - The unified foreign function interface (UnifiedFFI) for interfacing with > the outside world is significantly improved > - The PharoVM is now part of OpenSmalltalk initiative > - Introduction of object immutability, alternative bytecode sets and block > closures independent of outer context > - Pharo can now be bootstrapped from source code managed by Git > - Pharo modularity is improved > - Pharo is faster > - The Dark Theme was improved and set as default color theme of Pharo > > > These are just the more prominent highlights, but the details are just as > important. We have closed 1474 issues in Pharo 6.0 (a more complete > changelog can be found at > https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo60Change…) > > While the technical improvements are significant (starting the transition to > 64bits is a remarkable achievement), still the most impressive fact is that > the new code that got in the main Pharo 6.0 image was contributed by more > than 80 people. > > Pharo is more than code. It is an exciting project involving energetic > people. We thank all the contributors of this release: > > Alberto Bacchelli, Alejandro Infante, Alexandre Bergel, Aliaksei Syrel, > Alistair Grant, Andrei Chis, Ben Coman, Bernardo Contreras, Bernhard Pieber, > Boris Spasojevic, Christophe Demarey, Clement Bera, Cyril Ferlicot, Dale > Henrichs, Damien Cassou, Damien Pollet, Dave Lewis, Denis Kudriashov, Dirk > Roeleveld, Eliot Miranda, Esteban Lorenzano, Esteban Maringolo, Evan > Donahue, Federico Balaguer, Franck Warlouzet, Glenn Cavarle, Guillermo > Polito, Gustavo Santos, Henrik Johansen, Henrik Nergaard, Hilaire Fernandes, > Holger Hans, Jan Kurs, Jan van de Sandt, Johan Fabry, Juraj Kubelka, K. K. > Subramaniam, Ken Causey, Kris Gybels, Lionel Akue, Luc Fabresse, Lucas > Godoy, Marcus Denker, Mariano Martinez Peck, Marion Noirbent, Martin Dias, > Max Leske, Maxime Roelandt, Merwan Ouddane, Matteo Bellotto, Miguel > Campusano, Milton Mamani, Myroslava Romaniuk, Nicolai Hess, Nicolas Cellier, > Nicolas Passerini, Norbert Hartl, Offray Luna, Pablo Tesone, Paul De > Bruicker, Pavel Krivanek, Peter Uhnak, Philippe Back, Roger Stebler, Ronie > Salgado, Sean DeNigris, Serge Stinckwich, Skip Lentz, Sophie Kaleba, Stefan > Reichhart, Stephan Eggermont, Stephane Ducasse, Sven Van Caekenberghe, > Thibault Arloing, Thibault Arloing, Thibault Raffaillac, Thierry Goubier, > Thomas Heniart, Tommaso Dal Sasso, Torsten Bergmann, Tudor Girba, Udo > Schneider, Valentin Ryckewaert, Vincent Blondeau, Werner Kassens, Yuriy > Tymchuk > > (If you contributed with Pharo 6.0 development in any way and we missed your > name, please send us a mail and we will add you). > > Enjoy! > > The Pharo Team > > Try Pharo: http://pharo.org/download > Learn Pharo: http://pharo.org/documentation

June 7, 2017

Re: [Pharo-users] Some Metacello issue

by Stephan Eggermont

I would like to repeat here again: don't refer to fixed version numbers of packages out of your control in configurations. Refer to #'release' versions that can be patched by the maintainers of your dependencies. That is only appropriate when having to patch around a problem, and couples your configuration hard to the development schedule of your dependency, making it your responsibility to update your configuration whenever that of your dependency is updated. Stephan

June 7, 2017

Re: [Pharo-users] Some Metacello issue

by Stephan Eggermont

On 07/06/17 06:19, Holger Freyther wrote: > Hi, > > after having made some new releases I have an odd Metacello issue and > I am not sure how to debug it. This happens on my legacy > Pharo3/Pharo4 images that I still need to support in deployment. > > It seems to be related to a dependency chain of > "app"->VoyageMongo->Magritte3 3.5.0 and somehow version '3.1.1.1' of > Magritte3 doing something with Grease #stable and not finding a > 'Core' group. Any idea how to debug it or if any configuration > changed recently? It also only seems to happen if there are two > dependency chains that try to load the same VoyageMongo version. > Metacello new configuration: 'Magritte3'; repository: > 'http://www.smalltalkhub.com/mc/Magritte/Magritte3/main'; version: > '3.5.0'; load version: #'release35' (or #'release3' Never refer to fixed versions unless you know why (you need to avoid a specific bug fix). What is most likely is that there is some overconstrained configuration. Does your ConfigurationOfVoyageMongo or one of the configurations it pulls in refer to different versions of grease or magritte? Another issue can be that there are older configurations already loaded that conflict with the newest ones. Indeed, the ConfigurationOfMongoTalk is broken, refering to a fixed and older version of Grease. ConfigurationOfVoyageMongo should probably be using #'release3' of Magritte, but that doesn't break it. Stephan

June 7, 2017

Some Metacello issue

by Holger Freyther

Hi, after having made some new releases I have an odd Metacello issue and I am not sure how to debug it. This happens on my legacy Pharo3/Pharo4 images that I still need to support in deployment. It seems to be related to a dependency chain of "app"->VoyageMongo->Magritte3 3.5.0 and somehow version '3.1.1.1' of Magritte3 doing something with Grease #stable and not finding a 'Core' group. Any idea how to debug it or if any configuration changed recently? It also only seems to happen if there are two dependency chains that try to load the same VoyageMongo version. Broken: pharo Pharo3.image config http://smalltalkhub.com/mc/osmocom/Osmocom/main ConfigurationOfOsmoUniverse --install=bleedingEdge Error: Name not found: Core MetacelloMCVersionSpec(Object)>>error: MetacelloMCVersionSpec(MetacelloVersionSpec)>>resolveToLoadableSpec:forLoad:forMap:packages: in Block: [ ^ self error: 'Name not found: ' , aString ] MetacelloMCVersionSpec(MetacelloVersionSpec)>>packageNamed:forLoad:forMap:ifAbsent: in Block: [ ... Dictionary>>at:ifAbsent: MetacelloMCVersionSpec(MetacelloVersionSpec)>>packageNamed:forLoad:forMap:ifAbsent: MetacelloMCVersionSpec(MetacelloVersionSpec)>>resolveToLoadableSpec:forLoad:forMap:packages: MetacelloMCVersionSpec(MetacelloVersionSpec)>>resolveToLoadableSpecs:forLoad:map: in Block: [ :req | ... Array(SequenceableCollection)>>do: MetacelloMCVersionSpec(MetacelloVersionSpec)>>resolveToLoadableSpecs:forLoad:map: MetacelloMCVersionSpec(MetacelloVersionSpec)>>resolveToLoadableSpecs: MetacelloMCVersionSpec(MetacelloVersionSpec)>>expandToLoadableSpecNames: in Block: [ :cache | ... MetacelloPharo30Platform(MetacelloPlatform)>>stackCacheFor:cacheClass:at:doing: in Block: [ :dict | ... MetacelloPharo30Platform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: in Block: [ ^ aBlock value: dict ] BlockClosure>>on:do: ... Working: Metacello new configuration: 'Magritte3'; repository: 'http://www.smalltalkhub.com/mc/Magritte/Magritte3/main'; version: '3.5.0'; load

June 7, 2017

Tabular Data Structures for Data Analysis - Text Data Grooming

by Ben Coman

Hi Oleks, This is probably out of scope (check with your mentors), but I was curious how text processing and inter-table lookups might fit into you project? Check out the Excel side-story at [1] (starting just above the picture of the red tree) "Everybody thought of Excel as a financial modeling application [...] for creating calculation models with formulas and stuff. ... [but] most people just used Excel to make lists". This is exactly my personal experience. The greatest practical value I've had from Excel is massaging text lists. Some use cases: A. getting a bunch of messy hand typed data that needs cleaning up to be consistent before deriving statistics from it. There is no sense programming the whole workflow since its a highly iterative process to work through issues as you discover them. Issues are on-shot, but you want to apply it to 1000 rows. B. tracking the status of 1000s of drawings as they progress through a workflow. Tagging who is working on each drawing, status and using AutoFilter to print out "Drawings To Go" lists. C. managing a photo shoot for a school ball, recording orders and generating filenames to copy originals to a USB stick to take to the photo lab, such that duplicate orders each have a single file with the filename printed on the back making it easier to sort into envelopes for each order. (This is from last week so I can provide a sample Excel file for it) For a detailed example, sometimes I might need to compare the basenames of the files in two folders: 1. In both folders A & B, from the command line I'd do `ls -l > ls.txt` 2. I'd load both text files into Excel, one per tab, where each line appeared in a single column. 3. I split on spaces to convert single column into multiple columns [2] 4. I'd split off the filename extension. So I'd need to reverse the string to determine the location of the last period and store that in a temporary column. Then two more columns hold the formulas extracting the first and second parts of the split using LEFT() and RIGHT(). 5. Then in next column I'd have a formula using VLOOKUP() [4] to see if a row's basename appears in any row of the other tab. 6. I'd then do conditional formatting highlighting the row green if the VLOOKUP() was found. "Text Data Grooming" would be a popular horizonal application demonstrating Pharo's liveness (indeed Excel can be considered a "live" environment., saving its "image" to a xls file). I'd very much love to use Pharo for this instead of Excel. cheers -ben [1] https://www.joelonsoftware.com/2012/01/06/how-trello-is-different/ [2] https://support.office.com/en-us/article/Split-text-into-different-columns-… [3] https://superuser.com/questions/121618/any-excel-function-that-will-reverse… [4] https://support.office.com/en-us/article/VLOOKUP-function-0bbc8083-26fe-496…

June 7, 2017

Re: [Pharo-users] [ANN] Pharo 6.0 released!

by peter yoo

Congratulations! and thanks to Pharo DEV team!

June 7, 2017

Re: [Pharo-users] How to deploy headless app without changes and source files?

by Andreas Sunardi

For now, in my 'deployed' image, I have: 1. Disabled SourceFilesArray >> forceChangesToDisk I did not find any code branch that would avoid this, so for now I just made it do nothing. Maybe I should disable ChangesLog >> logChange: instead. 2. Disabled PharoFilesOpener >> changesFileOrNil Same story. But this only causes warning get printed out, not error. Disabling it removes the warning message. 3. Set changesFileStream to nil (SourceFiles changesFileStream: nil). Some code does have guard against nil value for this changes stream. This works for me if I do not have the changes file with the image. If I have the changes file and it's read-only, that's a different problem. It seems that this was possible before, judging from the older links I found in my original email and the existence of some guards against non-existence changes file. I'll check those links and perhaps see if I can be helpful there, but I right now have delivery to make. And I can't wait to try Pharo 6 too. -- Andreas On Tue, Jun 6, 2017 at 6:37 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Wed, Jun 7, 2017 at 3:23 AM, Andreas Sunardi <a.sunardi(a)gmail.com> > wrote: > >> Hi Stef, >> >> I can't have changes file bundled with the tool because the tool is >> installed in a centralized location in my network and multiple users will >> run it. So the image is in a central location and read-only and so is the >> changes file (if I must have a changes file). The tool is only a processor. >> It does not need to keep/save its state. >> >> Hence, I cannot have multiple users writing to that one and the same >> changes file. >> >> I'm trying to dissect the call chain to ChangesLog and try to cut it so >> Pharo won't write to the changes file. I'm sure I should not do this. There >> must be a better way. >> > > I guess this use case just hasn't been critical for other people (there > are lots of competing priorities) and they've found ways of working around > it, like making your network located tool a script that copies itself > itself to a use folder and run from there. But of course it would be > better for Pharo to work cleanly without a changes file. To make it better, > someone has to do it, so feel free to propose some code changes (with > discussion of such on pharo-dev list). > > Here is one hint (something related I worked on recently)... > https://pharo.fogbugz.com/f/cases/20074/Red-pane-of-death- > when-sources-file-missing > To view the changes, open image 60494 (easiest using PharoLauncher) > and load the slice. > > Filtering the issue tracker on "changes file" pops up a few other > possibilities (I haven't reviewed them, and you might find others) > https://pharo.fogbugz.com/f/cases/11204/Crash-if-changes- > file-is-not-writable > https://pharo.fogbugz.com/f/cases/11426/Extract-the-logic- > that-opens-the-sources-and-changes-files > > cheers -ben > > >> >> On Tue, Jun 6, 2017 at 11:55 AM, Stephane Ducasse < >> stepharo.self(a)gmail.com> wrote: >> >>> We started to work on making the system ready to stop using these files. >>> There are two things. >>> - the changes are a tape that logs what you are doing and right now >>> the system is not done to accept not to log >>> So I imagine that you can remove the changes file but then do not >>> compile code. >>> - I do not get the "so I can't have changes file bundled with the tool." >>> you do not have a bat or script that launches the application that is >>> somewhere in a folder where you have the vm and the image? you could >>> have the changes file there. >>> >>> We are interested in your scenario because last year I got a guy >>> working on making pharo silent. I do not know if its changes got >>> integrated into pharo. >>> This is really something that we want to have. >>> - having sources and changes in a specific location >>> - having no source and no changes (even if it means lose your code). >>> - ... >>> >>> Stef >>> >>> On Tue, Jun 6, 2017 at 8:14 PM, Andreas Sunardi <a.sunardi(a)gmail.com> >>> wrote: >>> > Sorry to bring this up again. But it turns out that I had the image >>> > directory writable by myself, so it created a new changes file. That's >>> why >>> > Pharo didn't complain about missing changes file. When I removed write >>> > permission in the tool installation, Pharo gives error for not having >>> or not >>> > able to write to changes file. >>> > >>> > I guess I'm back to the problem how to deploy a tool without changes >>> file. I >>> > have multiple users that will be running this tool, which is installed >>> in a >>> > centralized site, so I can't have changes file bundled with the tool. >>> > >>> > On Mon, Jun 5, 2017 at 5:47 PM, Andreas Sunardi <a.sunardi(a)gmail.com> >>> wrote: >>> >> >>> >> I had my changes and sources files in the bundle but has their write >>> >> permission removed, and that causes the error. Simply deploying the >>> tool >>> >> without the changes file seems to fix it. Pharo5 doesn't complain if >>> the >>> >> changes file isn't there. >>> >> >>> >> However, without the sources file, I get this warning that pharo >>> cannot >>> >> locate the sources file. Including the sources file in the deployed >>> tool is >>> >> fine with me. >>> >> >>> >> So, I think that's my solution. Thanks! >>> >> >>> >> >>> >> On Mon, Jun 5, 2017 at 5:07 PM, Andreas Sunardi <a.sunardi(a)gmail.com> >>> >> wrote: >>> >>> >>> >>> I found this StackOverflow question: >>> >>> >>> >>> https://stackoverflow.com/questions/14737695/is-it-possible- >>> to-deploy-a-pharo-image-without-changes-and-sources-files/14747328 >>> >>> >>> >>> and this older forum thread: >>> >>> >>> >>> https://www.mail-archive.com/pharo-project@lists.gforge.inri >>> a.fr/msg21170.html >>> >>> >>> >>> I'm using Pharo5.0 and neither of these options is available anymore. >>> >>> What is the new way to do this? >>> >>> >>> >>> -- >>> >>> Andreas Sunardi >>> >> >>> >> >>> > >>> >>> >> >

June 7, 2017

Re: [Pharo-users] How to deploy headless app without changes and source files?

by Ben Coman

On Wed, Jun 7, 2017 at 3:23 AM, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: > Hi Stef, > > I can't have changes file bundled with the tool because the tool is > installed in a centralized location in my network and multiple users will > run it. So the image is in a central location and read-only and so is the > changes file (if I must have a changes file). The tool is only a processor. > It does not need to keep/save its state. > > Hence, I cannot have multiple users writing to that one and the same > changes file. > > I'm trying to dissect the call chain to ChangesLog and try to cut it so > Pharo won't write to the changes file. I'm sure I should not do this. There > must be a better way. > I guess this use case just hasn't been critical for other people (there are lots of competing priorities) and they've found ways of working around it, like making your network located tool a script that copies itself itself to a use folder and run from there. But of course it would be better for Pharo to work cleanly without a changes file. To make it better, someone has to do it, so feel free to propose some code changes (with discussion of such on pharo-dev list). Here is one hint (something related I worked on recently)... https://pharo.fogbugz.com/f/cases/20074/Red-pane-of-death-when-sources-file… To view the changes, open image 60494 (easiest using PharoLauncher) and load the slice. Filtering the issue tracker on "changes file" pops up a few other possibilities (I haven't reviewed them, and you might find others) https://pharo.fogbugz.com/f/cases/11204/Crash-if-changes-file-is-not-writab… https://pharo.fogbugz.com/f/cases/11426/Extract-the-logic-that-opens-the-so… cheers -ben > > On Tue, Jun 6, 2017 at 11:55 AM, Stephane Ducasse <stepharo.self(a)gmail.com > > wrote: > >> We started to work on making the system ready to stop using these files. >> There are two things. >> - the changes are a tape that logs what you are doing and right now >> the system is not done to accept not to log >> So I imagine that you can remove the changes file but then do not compile >> code. >> - I do not get the "so I can't have changes file bundled with the tool." >> you do not have a bat or script that launches the application that is >> somewhere in a folder where you have the vm and the image? you could >> have the changes file there. >> >> We are interested in your scenario because last year I got a guy >> working on making pharo silent. I do not know if its changes got >> integrated into pharo. >> This is really something that we want to have. >> - having sources and changes in a specific location >> - having no source and no changes (even if it means lose your code). >> - ... >> >> Stef >> >> On Tue, Jun 6, 2017 at 8:14 PM, Andreas Sunardi <a.sunardi(a)gmail.com> >> wrote: >> > Sorry to bring this up again. But it turns out that I had the image >> > directory writable by myself, so it created a new changes file. That's >> why >> > Pharo didn't complain about missing changes file. When I removed write >> > permission in the tool installation, Pharo gives error for not having >> or not >> > able to write to changes file. >> > >> > I guess I'm back to the problem how to deploy a tool without changes >> file. I >> > have multiple users that will be running this tool, which is installed >> in a >> > centralized site, so I can't have changes file bundled with the tool. >> > >> > On Mon, Jun 5, 2017 at 5:47 PM, Andreas Sunardi <a.sunardi(a)gmail.com> >> wrote: >> >> >> >> I had my changes and sources files in the bundle but has their write >> >> permission removed, and that causes the error. Simply deploying the >> tool >> >> without the changes file seems to fix it. Pharo5 doesn't complain if >> the >> >> changes file isn't there. >> >> >> >> However, without the sources file, I get this warning that pharo cannot >> >> locate the sources file. Including the sources file in the deployed >> tool is >> >> fine with me. >> >> >> >> So, I think that's my solution. Thanks! >> >> >> >> >> >> On Mon, Jun 5, 2017 at 5:07 PM, Andreas Sunardi <a.sunardi(a)gmail.com> >> >> wrote: >> >>> >> >>> I found this StackOverflow question: >> >>> >> >>> https://stackoverflow.com/questions/14737695/is-it-possible- >> to-deploy-a-pharo-image-without-changes-and-sources-files/14747328 >> >>> >> >>> and this older forum thread: >> >>> >> >>> https://www.mail-archive.com/pharo-project@lists.gforge.inri >> a.fr/msg21170.html >> >>> >> >>> I'm using Pharo5.0 and neither of these options is available anymore. >> >>> What is the new way to do this? >> >>> >> >>> -- >> >>> Andreas Sunardi >> >> >> >> >> > >> >> >

June 7, 2017