Don't want to see a particular notification
Hi, in SmalltalkImage>>checkAndOpenSourcesAndChanges, there is some code that looks like this: [...] changes isReadOnly ifTrue: [ self inform: 'Pharo cannot write to the changes file ...' ]. [...] This code raises a warning if the changes file can't be written to. In the PharoLauncher case, the image and changes file won't be writable and it is ok (they will be in a place like /usr/lib). I certainly don't want my users to see this warning. What can I do please? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
On Jul 21, 2013, at 10:05 AM, Damien Cassou <damien.cassou@gmail.com> wrote:
Hi,
in SmalltalkImage>>checkAndOpenSourcesAndChanges, there is some code that looks like this:
[...] changes isReadOnly ifTrue: [ self inform: 'Pharo cannot write to the changes file ...' ]. [...]
This code raises a warning if the changes file can't be written to. In the PharoLauncher case, the image and changes file won't be writable and it is ok (they will be in a place like /usr/lib). I certainly don't want my users to see this warning.
What can I do please?
We need to get rid of .changes and .sources⦠it will solve all kinds of problems. Marcus
Am 21.07.2013 um 10:16 schrieb Marcus Denker <marcus.denker@inria.fr>:
On Jul 21, 2013, at 10:05 AM, Damien Cassou <damien.cassou@gmail.com> wrote:
Hi,
in SmalltalkImage>>checkAndOpenSourcesAndChanges, there is some code that looks like this:
[...] changes isReadOnly ifTrue: [ self inform: 'Pharo cannot write to the changes file ...' ]. [...]
This code raises a warning if the changes file can't be written to. In the PharoLauncher case, the image and changes file won't be writable and it is ok (they will be in a place like /usr/lib). I certainly don't want my users to see this warning.
What can I do please?
We need to get rid of .changes and .sources⦠it will solve all kinds of problems.
What will be the replacement? Norbert
On Jul 21, 2013, at 10:20 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 21.07.2013 um 10:16 schrieb Marcus Denker <marcus.denker@inria.fr>:
On Jul 21, 2013, at 10:05 AM, Damien Cassou <damien.cassou@gmail.com> wrote:
Hi,
in SmalltalkImage>>checkAndOpenSourcesAndChanges, there is some code that looks like this:
[...] changes isReadOnly ifTrue: [ self inform: 'Pharo cannot write to the changes file ...' ]. [...]
This code raises a warning if the changes file can't be written to. In the PharoLauncher case, the image and changes file won't be writable and it is ok (they will be in a place like /usr/lib). I certainly don't want my users to see this warning.
What can I do please?
We need to get rid of .changes and .sources⦠it will solve all kinds of problems.
What will be the replacement?
-> transaction log attached to he end of the running image file -> accepted methods kept in image history until next commit to the source repo -> sources in image. First compresses text with a shared compression dictionary, later a high-level representation of code that superseded the AST, text and bytecode. Yes, and I know that everyone things that this is wrong. And I don't care :-) Marcus
Am 21.07.2013 um 10:32 schrieb Marcus Denker <marcus.denker@inria.fr>:
On Jul 21, 2013, at 10:20 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 21.07.2013 um 10:16 schrieb Marcus Denker <marcus.denker@inria.fr>:
On Jul 21, 2013, at 10:05 AM, Damien Cassou <damien.cassou@gmail.com> wrote:
Hi,
in SmalltalkImage>>checkAndOpenSourcesAndChanges, there is some code that looks like this:
[...] changes isReadOnly ifTrue: [ self inform: 'Pharo cannot write to the changes file ...' ]. [...]
This code raises a warning if the changes file can't be written to. In the PharoLauncher case, the image and changes file won't be writable and it is ok (they will be in a place like /usr/lib). I certainly don't want my users to see this warning.
What can I do please?
We need to get rid of .changes and .sources⦠it will solve all kinds of problems.
What will be the replacement?
-> transaction log attached to he end of the running image file
Ok, sounds reasonable on the one hand (getting rid of an additional file) and dangerous on the other hand (on image write the transaction log needs to be read/written/moved making it possible to loose image and transaction log. Think about a "disk full" scenario). How is this covered?
-> accepted methods kept in image history until next commit to the source repo
Great. Everyone can have a ImmediateCommitStrategy so no reason to complain, right?
-> sources in image. First compresses text with a shared compression dictionary, later a high-level representation of code that superseded the AST, text and bytecode.
That is really cool. There is no reason to have sources separate until you treat it like text you basicall don't care about. I'm curious with what you'll come up with regarding the thing that supersedes ast, text and bytecode. And especially if the visual syntax can still be the same as it is now. As you know I would be a fan of something that would keep the smalltalk syntax (meaning visual characters) the same but adds visual things (colors, icons, type setting) to indicate the presence of meta data. Underneath there be something that can transport the code with an extended source format to another image. Cool times are these.
Yes, and I know that everyone things that this is wrong. And I don't care :-)
Come on. Things aren't that bad. Just imagine that all of the people that aren't complaining do agree or don't care about. And that's a way bigger number. I personally like those steps even if it means we are loosing a lot of tools and frameworks out there (And there aren't that many) Norbert
-> transaction log attached to he end of the running image file
Ok, sounds reasonable on the one hand (getting rid of an additional file) and dangerous on the other hand (on image write the transaction log needs to be read/written/moved making it possible to loose image and transaction log. Think about a "disk full" scenario). How is this covered?
For the change log: it will stop recording (like now when there is no space for .changes appending) Image save: right now you override the existing file, this means that if you don't have enough space for you (likely) larger image, it will fail and override the old image. New: it will fail, but while writing the *new* file. So you at least keep your old. In both cases you can't write a new image file, but right now you loose your old one, too. So it's better.
-> accepted methods kept in image history until next commit to the source repo
Great. Everyone can have a ImmediateCommitStrategy so no reason to complain, right?
Yes, it is the same as now: you loose the "method save" commits as only what is in Monticello is saved for real.
-> sources in image. First compresses text with a shared compression dictionary, later a high-level representation of code that superseded the AST, text and bytecode.
That is really cool. There is no reason to have sources separate until you treat it like text you basicall don't care about. I'm curious with what you'll come up with regarding the thing that supersedes ast, text and bytecode. And especially if the visual syntax can still be the same as it is now. As you know I would be a fan of something that would keep the smalltalk syntax (meaning visual characters) the same but adds visual things (colors, icons, type setting) to indicate the presence of meta data. Underneath there be something that can transport the code with an extended source format to another image. Cool times are these.
The idea would be to keep it at the beginning just the same: instead of a stream of characters, the data structure would be different, but would be just s string form what it shows. (this means no changes to MC, Git, or even file out). Purely internal.
Yes, and I know that everyone things that this is wrong. And I don't care :-)
Come on. Things aren't that bad.
:-)
Just imagine that all of the people that aren't complaining do agree or don't care about. And that's a way bigger number. I personally like those steps even if it means we are loosing a lot of tools and frameworks out there (And there aren't that many)
I think nothing works directly on the .source and .changes right now⦠so one would loose nothing. (Of course after there are other things thinkable⦠but that is for after). Marcus
Hi pharoers I think that doing is more difficult than evolving :) So before this scenario happens, I want to have a new changes management system that is orthogonal to the source management. Right now these two concepts are mixed together. Martin in the context of his PhD is working on a nice replacement to changeset and also he is building a nice representation of a change (in the spirit of deltaStream) with changes representation and not just method, class, package. The project is called Epicea. We want to support for example: - I perform a list of changes - I tagged them with comments like refactored this method into these two - publish the code - and Alain can review my code at the level of the semantic change by looking and commenting on changes using the tags. I hope to get a nice demo for ESUG :) Stef
Hi,
in SmalltalkImage>>checkAndOpenSourcesAndChanges, there is some code that looks like this:
[...] changes isReadOnly ifTrue: [ self inform: 'Pharo cannot write to the changes file ...' ]. [...]
This code raises a warning if the changes file can't be written to. In the PharoLauncher case, the image and changes file won't be writable and it is ok (they will be in a place like /usr/lib). I certainly don't want my users to see this warning.
What can I do please?
We need to get rid of .changes and .sources⦠it will solve all kinds of problems.
What will be the replacement?
-> transaction log attached to he end of the running image file
Ok, sounds reasonable on the one hand (getting rid of an additional file) and dangerous on the other hand (on image write the transaction log needs to be read/written/moved making it possible to loose image and transaction log. Think about a "disk full" scenario). How is this covered?
-> accepted methods kept in image history until next commit to the source repo
Great. Everyone can have a ImmediateCommitStrategy so no reason to complain, right?
-> sources in image. First compresses text with a shared compression dictionary, later a high-level representation of code that superseded the AST, text and bytecode.
That is really cool. There is no reason to have sources separate until you treat it like text you basicall don't care about. I'm curious with what you'll come up with regarding the thing that supersedes ast, text and bytecode. And especially if the visual syntax can still be the same as it is now. As you know I would be a fan of something that would keep the smalltalk syntax (meaning visual characters) the same but adds visual things (colors, icons, type setting) to indicate the presence of meta data. Underneath there be something that can transport the code with an extended source format to another image. Cool times are these.
Yes, and I know that everyone things that this is wrong. And I don't care :-)
Come on. Things aren't that bad. Just imagine that all of the people that aren't complaining do agree or don't care about. And that's a way bigger number. I personally like those steps even if it means we are loosing a lot of tools and frameworks out there (And there aren't that many)
Norbert
How about SmalltalkImage checkChangesFileAvailability: false. ? Norbert Am 21.07.2013 um 10:04 schrieb Damien Cassou <damien.cassou@gmail.com>:
Hi,
in SmalltalkImage>>checkAndOpenSourcesAndChanges, there is some code that looks like this:
[...] changes isReadOnly ifTrue: [ self inform: 'Pharo cannot write to the changes file ...' ]. [...]
This code raises a warning if the changes file can't be written to. In the PharoLauncher case, the image and changes file won't be writable and it is ok (they will be in a place like /usr/lib). I certainly don't want my users to see this warning.
What can I do please?
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
On Sun, Jul 21, 2013 at 10:18 AM, Norbert Hartl <norbert@hartl.name> wrote:
SmalltalkImage checkChangesFileAvailability: false.
Thank you Norbert, but this method does not exist -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
May be we should refactor the code so that we can specify if the warning should be raised or not.
Hi,
in SmalltalkImage>>checkAndOpenSourcesAndChanges, there is some code that looks like this:
[â¦] changes isReadOnly ifTrue: [ self inform: 'Pharo cannot write to the changes file ...' ]. [...]
This code raises a warning if the changes file can't be written to. In the PharoLauncher case, the image and changes file won't be writable and it is ok (they will be in a place like /usr/lib). I certainly don't want my users to see this warning.
What can I do please?
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
On Sun, Jul 21, 2013 at 12:10 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
May be we should refactor the code so that we can specify if the warning should be raised or not.
this happens at startup. Do you have an idea in mind? Should I add an instance variable for that? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
On Jul 21, 2013, at 6:39 PM, Damien Cassou <damien.cassou@gmail.com> wrote:
On Sun, Jul 21, 2013 at 12:10 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
May be we should refactor the code so that we can specify if the warning should be raised or not.
this happens at startup. Do you have an idea in mind? Should I add an instance variable for that?
why not? Let us use our tool to tame complexity.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
participants (4)
-
Damien Cassou -
Marcus Denker -
Norbert Hartl -
Stéphane Ducasse