- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40250 Home: https://github.com/pharo-project/pharo-core

Sept. 24, 2014

Re: [Pharo-dev] Gitfiletree github diff

by Yuriy Tymchuk

I open monticello browser, select my package, and I have associated github repositoryâ¦ Wait. Maybe it is not gitfiletreeâs error because that repository is installed with metacello github magic. But yes, wen I clock on âchangesâ button I get the error. Uko > On 24 Sep 2014, at 17:10, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Uko, > > where do you get that error? From inside Pharo? Or when browsing on github? > > Thierry > > 2014-09-24 16:48 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: > Hi, > > I use gitfiletree and when I want to see changes with my github repo, I get: "SSL Exception: decrypt failed [code:-5]â. But only first time, all other times it works well. Any ideas where can be the problem? > > Uko >

Sept. 24, 2014

Re: [Pharo-dev] Gitfiletree github diff

by Thierry Goubier

Hi Uko, where do you get that error? From inside Pharo? Or when browsing on github? Thierry 2014-09-24 16:48 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Hi, > > I use gitfiletree and when I want to see changes with my github repo, I > get: "SSL Exception: decrypt failed [code:-5]". But only first time, all > other times it works well. Any ideas where can be the problem? > > Uko >

Sept. 24, 2014

Re: [Pharo-dev] deployment components

by phil＠highoctane.be

On Wed, Sep 24, 2014 at 4:32 PM, Craig Latta <craig(a)netjam.org> wrote: > > Hi-- > > > Actually, I am fine with the prefixes. Objective-C also works like > > that and well, it hasn't exactly hampered its community to scale. > > I think Objective-C might have had one or two other forces behind > it to compensate. :) > Sure. But not when it was at NeXT. > > > I have done my share of Java and yeah, sure, there are a lot of > > enterprise grade things in there. So many that actual development and > > delivery usually slows down to a crawl with lots of Java priests who > > confuse delivery of business value with technical show off. > > For me this stuff isn't about being "enterprise-grade" or even > particularly sophisticated. It's rudimentary, like bothering to remember > where your car is parked. The lack of it is something that causes > potential participants I meet to stop listening, especially given the > power of the system in general. It's a strange discontinuity. > Looks like this thing as been discusses ad libitum in the past... I actually like this one: http://swiki.krampe.se/gohu/32 Looks like no nonsense and not forcing anything down people throats. Phil > > -C > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > >

Sept. 24, 2014

Gitfiletree github diff

by Yuriy Tymchuk

Hi, I use gitfiletree and when I want to see changes with my github repo, I get: "SSL Exception: decrypt failed [code:-5]â. But only first time, all other times it works well. Any ideas where can be the problem? Uko

Sept. 24, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40249 Home: https://github.com/pharo-project/pharo-core

Sept. 24, 2014

[pharo-project/pharo-core] 718944: 40249

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 7189449ac0f0cd0ff2711f0cd5cfd843bf6eb071 https://github.com/pharo-project/pharo-core/commit/7189449ac0f0cd0ff2711f0c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-09-24 (Wed, 24 Sep 2014) Changed paths: A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script249.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40249.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForIssues_.st M Spec-MorphicAdapters.package/WorldModel.class/class/private/setUpWorld.st Log Message: ----------- 40249 14065 Spec WorldModel should not change theme background https://pharo.fogbugz.com/f/cases/14065 http://files.pharo.org/image/40/40249.zip

Sept. 24, 2014

Re: [Pharo-dev] deployment components

by Craig Latta

Hi Torsten-- > The interesting part is not to add all kind of stuff to Smalltalk - > the interesting part is what is the most minimalistic system to allow > for something extensible and still flexible (even within the > meta-system) so that one can bootstrap things on top. Yes, that's my interest precisely. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Sept. 24, 2014

Re: [Pharo-dev] deployment components

by Craig Latta

Hi Frank-- I wrote: > Right, there's no need for anyone to use UUIDs when referring to > classes in Smalltalk expressions. Torsten responded: > Yes, exactly this. We still use regular names for the classes - but > for the tools they have a distinguishable ID. Best is to use a UUID > for the ID as it is unique from the beginning. So if you create a > class "Foo" and I create one both are unqique by ID - even when using > the same name. You responded to Torsten: > The problem I have with UUIDs is that... Hooray! Discussion! :) > ...in a distributed setting, you need to rely on everyone to generate > UUIDs correctly. Now IF everyone implements UUID generation > correctly... This is not hard, if there are common implementations at the Smalltalk level (like we have common collection classes), or at the virtual machine level (like we have common plugins). > ...and IF everyone plays the game in good faith... Whoa, if you're going to invoke that concern, then I wonder how you can tolerate what we've already been doing. Namely: - Compiling source code with no way to trust its authorship. - Compiling source code with no way to trust that the code does what the authors say it does (trusting authorship would help somewhat). - Compiling source code with no way to trust that the target compilation environment is sufficiently like the one in which the source code was developed. > ...you will almost certainly not get a UUID clash. But when you say > your code depends on package/class/object/method with guid SOME_GUID, > and I as a bad actor inject my own class with guid SOME_GUID, how are > you to know that you've just been 0wned? Again, how would you know today that the filein or Monticello package you just loaded has 0wned you? When would you know? What would you do about it? I think we have to concede that a motivated insider will always be able to do bad things for a while before being caught, probably involving social mechanisms. I'm interested in how to minimize this time, and how to undo the bad things. With the Naiad module system, I want to identify, as soon as possible, the human interactions required to establish trust, and facilitate them. Naiad modules are synchronized live between systems (without recompiling source code; only authors compile source code). You could know you're likely to be 0nwed if you proceed with a module synchronization because the cryptographic signature of a module is incorrect for its purported authors. It would be similar to knowing that the PGP-signed message you just read isn't really from the person whose key you verified earlier. > Wouldn't it be better, instead of using a key-value store (key K maps > to value V), we have a store that uses function_of(V) maps to value V? > Like in git: a commit is uniquely identified by its hash and, because > the hash is a checksum, you can't - short of engineering a SHA-1 > collision (good luck with that) - forge part of the system. The things we want to identify have state that changes over time; their hashes would also change over time. This is fine for things like a module signature during a synchronization conversation (in fact, I'd like to leverage the actual existing public-key cryptography infrastructure for Naiad). It's inappropriate for referring to a changing class over the course of years. UUIDs are a straightforward and well-known way of generating IDs for things which change. Anyway, there it is, both UUIDs and hashing are involved. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Sept. 24, 2014

Re: [Pharo-dev] deployment components

by Craig Latta

Hi-- > Actually, I am fine with the prefixes. Objective-C also works like > that and well, it hasn't exactly hampered its community to scale. I think Objective-C might have had one or two other forces behind it to compensate. :) > I have done my share of Java and yeah, sure, there are a lot of > enterprise grade things in there. So many that actual development and > delivery usually slows down to a crawl with lots of Java priests who > confuse delivery of business value with technical show off. For me this stuff isn't about being "enterprise-grade" or even particularly sophisticated. It's rudimentary, like bothering to remember where your car is parked. The lack of it is something that causes potential participants I meet to stop listening, especially given the power of the system in general. It's a strange discontinuity. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Sept. 24, 2014