[Pharo-project] [ANN] ZTimestamp[Precise]SNTPClient
Hi, It is often important, especially for server applications, to know if the current local clock is still OK. The standard way for doing that is part of NTP (http://en.wikipedia.org/wiki/Network_Time_Protocol). I implemented two SNTP clients (one with ZTimestamp's second precision and another one using DateAndTime's nanosecond precision) that can be used to check the difference between the local clock and the clock of any NTP server. ZTimestampPreciseSNTPClient new clockDifference. -0:00:00:00.005786228 This reports that the difference between the local and remote clocks is in the order of 5ms, as computed in one specific way. Other queries are related to the Clock synchronisation algorithm. ZTimestampPreciseSNTPClient new localClockOffset. 0:00:00:00.065466869 ZTimestampPreciseSNTPClient new roundtripDelay. 0:00:00:00.037001908 In practice the following would be a useful practical check. ZTimestampPreciseSNTPClient new enforceClockDifference: 2 seconds ifFail: [ :delta | self warn: ('Clock difference {1} > 2s' format: { delta }) ]; close. As NTP uses UDP datagrams, this is a nice example for that as well. The code can be found in the following repository: http://mc.stfx.eu/Neo It is probably easiest to load the ZTimestamp configuration using the Configuration Browser and then load the bleeding edge version (it is not in de released version). The code is self-contained and loads cleanly. ConfigurationOfZTimestamp project bleedingEdge load. The client contacts a server from pool.ntp.org. The code does only deal with a limited aspect of NTP, which is rather complex and wonderful subject matter (http://tools.ietf.org/html/rfc2030). My goal was to get a dependable result, not be be super accurate. Enjoy. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
I love the complete ecosystem you are step by step building. This is so great! Stef On Feb 26, 2013, at 1:42 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi,
It is often important, especially for server applications, to know if the current local clock is still OK. The standard way for doing that is part of NTP (http://en.wikipedia.org/wiki/Network_Time_Protocol). I implemented two SNTP clients (one with ZTimestamp's second precision and another one using DateAndTime's nanosecond precision) that can be used to check the difference between the local clock and the clock of any NTP server.
ZTimestampPreciseSNTPClient new clockDifference.
-0:00:00:00.005786228
This reports that the difference between the local and remote clocks is in the order of 5ms, as computed in one specific way. Other queries are related to the Clock synchronisation algorithm.
ZTimestampPreciseSNTPClient new localClockOffset.
0:00:00:00.065466869
ZTimestampPreciseSNTPClient new roundtripDelay.
0:00:00:00.037001908
In practice the following would be a useful practical check.
ZTimestampPreciseSNTPClient new enforceClockDifference: 2 seconds ifFail: [ :delta | self warn: ('Clock difference {1} > 2s' format: { delta }) ]; close.
As NTP uses UDP datagrams, this is a nice example for that as well. The code can be found in the following repository:
It is probably easiest to load the ZTimestamp configuration using the Configuration Browser and then load the bleeding edge version (it is not in de released version). The code is self-contained and loads cleanly.
ConfigurationOfZTimestamp project bleedingEdge load.
The client contacts a server from pool.ntp.org. The code does only deal with a limited aspect of NTP, which is rather complex and wonderful subject matter (http://tools.ietf.org/html/rfc2030). My goal was to get a dependable result, not be be super accurate.
Enjoy.
Sven
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
On Feb 26, 2013, at 4:57 PM, stephane ducasse <stephane.ducasse@free.fr> wrote:
I love the complete ecosystem you are step by step building. This is so great!
Yes! Just imagine we continue like that⦠we are now (slowly, slowly) reaching a point where for the first time we can really build on top of the foundation we did. One central idea behind Pharo was to so we can do better on top of what we did. The effect we will get from that will be very interesting. Until now we have seen almost nothing, but now we are entering a phase where the difference will be not very pronounced but visible if you look for it. Reflective improvement, leading to a feedback loop⦠and thus non-linear effects. I know that some people are laughing about this, but I really believe in it :-) Marcus
2013/2/26 Marcus Denker <marcus.denker@inria.fr>:
On Feb 26, 2013, at 4:57 PM, stephane ducasse <stephane.ducasse@free.fr> wrote:
I love the complete ecosystem you are step by step building. This is so great!
Yes! Just imagine we continue like that⦠we are now (slowly, slowly) reaching a point where for the first time we can really build on top of the foundation we did.
If you count the number of packages in SmalltalkHub and compare them to the ones in Npmjs.org, it is impressive how much we have. Of course NPM's user base is two orders of magnitude greater, but we need to start having more killer app "modules", and some sort of guideline for those starting with Pharo and/or Smalltalk. And of course, be open to the suggestions of newcomers. Regards, E.
On Feb 26, 2013, at 5:33 PM, "Esteban A. Maringolo" <emaringolo@gmail.com> wrote:
2013/2/26 Marcus Denker <marcus.denker@inria.fr>:
On Feb 26, 2013, at 4:57 PM, stephane ducasse <stephane.ducasse@free.fr> wrote:
I love the complete ecosystem you are step by step building. This is so great!
Yes! Just imagine we continue like that⦠we are now (slowly, slowly) reaching a point where for the first time we can really build on top of the foundation we did.
If you count the number of packages in SmalltalkHub and compare them to the ones in Npmjs.org, it is impressive how much we have.
But isn't "package" more like "repository" on smalltalkhub?
Of course NPM's user base is two orders of magnitude greater, but we need to start having more killer app "modules", and some sort of guideline for those starting with Pharo and/or Smalltalk.
And we need a system in the first place like that⦠smalltalkhub is more for code repositories, not in itself a repository of installable entities. So there is a lot of work ahead⦠but we will get there. Marcus
On Tue, Feb 26, 2013 at 5:39 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On Feb 26, 2013, at 5:33 PM, "Esteban A. Maringolo" <emaringolo@gmail.com> wrote:
2013/2/26 Marcus Denker <marcus.denker@inria.fr>:
On Feb 26, 2013, at 4:57 PM, stephane ducasse <stephane.ducasse@free.fr> wrote:
I love the complete ecosystem you are step by step building. This is so great!
Yes! Just imagine we continue like that⦠we are now (slowly, slowly) reaching a point where for the first time we can really build on top of the foundation we did.
If you count the number of packages in SmalltalkHub and compare them to the ones in Npmjs.org, it is impressive how much we have.
But isn't "package" more like "repository" on smalltalkhub?
Of course NPM's user base is two orders of magnitude greater, but we need to start having more killer app "modules", and some sort of guideline for those starting with Pharo and/or Smalltalk.
And we need a system in the first place like that⦠smalltalkhub is more for code repositories, not in itself a repository of installable entities.
So there is a lot of work ahead⦠but we will get there.
This is a great strength of programming languages like Ruby or JavaScript/Node to propose large repositories of packages that could be installed very easily with all the correct dependencies. Nice to see that thanks to the guys from INRIA (and more generally from the community), the Pharo ecosystem is following the same way. I also agree with Marcus that the day will come where the progress will be more visible. I'm currently on the way to move all my packages from SqueakSource to SmalltalkHub. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://doesnotunderstand.org/
Serge what is important is to produce configuration for the projects. We are working on a tool to help us with that but this is not ready yet.
This is a great strength of programming languages like Ruby or JavaScript/Node to propose large repositories of packages that could be installed very easily with all the correct dependencies.
Nice to see that thanks to the guys from INRIA (and more generally from the community), the Pharo ecosystem is following the same way. I also agree with Marcus that the day will come where the progress will be more visible.
I'm currently on the way to move all my packages from SqueakSource to SmalltalkHub.
Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://doesnotunderstand.org/
2013/2/26 Marcus Denker <marcus.denker@inria.fr>:
On Feb 26, 2013, at 5:33 PM, "Esteban A. Maringolo" <emaringolo@gmail.com> wrote:
If you count the number of packages in SmalltalkHub and compare them to the ones in Npmjs.org, it is impressive how much we have. But isn't "package" more like "repository" on smalltalkhub?
It is a Project, but on the explore screen it says Packages, so... who knows? :) But it is true that GitHub is to SmalltakHub what npm/gem is to...?
Of course NPM's user base is two orders of magnitude greater, but we need to start having more killer app "modules", and some sort of guideline for those starting with Pharo and/or Smalltalk. And we need a system in the first place like that⦠smalltalkhub is more for code repositories, not in itself a repository of installable entities.
Yes, having packages as "artifacts" is more straightforward than the configurations and all that jazz. The MetaRepo is going in that direction, but I still think that evaluating the install statements with Gofer or anything similar in a Workspace is somehow alien for a non smalltalker. There should be something that wraps Gofer and works like the apt, npm or gem commands.
So there is a lot of work ahead⦠but we will get there.
No doubts of that. Regards!
On 26 February 2013 18:33, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2013/2/26 Marcus Denker <marcus.denker@inria.fr>:
On Feb 26, 2013, at 5:33 PM, "Esteban A. Maringolo" <emaringolo@gmail.com> wrote:
If you count the number of packages in SmalltalkHub and compare them to the ones in Npmjs.org, it is impressive how much we have. But isn't "package" more like "repository" on smalltalkhub?
It is a Project, but on the explore screen it says Packages, so... who knows? :)
But it is true that GitHub is to SmalltakHub what npm/gem is to...?
No. GitHub and SmalltalkHub are repositories. Rubygems for Ruby (or clojars for Clojure, or CPAN for Perl) - are like SqueakMap - catalogs that point to packages/applications. frank
Of course NPM's user base is two orders of magnitude greater, but we need to start having more killer app "modules", and some sort of guideline for those starting with Pharo and/or Smalltalk. And we need a system in the first place like that⦠smalltalkhub is more for code repositories, not in itself a repository of installable entities.
Yes, having packages as "artifacts" is more straightforward than the configurations and all that jazz.
The MetaRepo is going in that direction, but I still think that evaluating the install statements with Gofer or anything similar in a Workspace is somehow alien for a non smalltalker.
There should be something that wraps Gofer and works like the apt, npm or gem commands.
So there is a lot of work ahead⦠but we will get there.
No doubts of that.
Regards!
Hi Frank, 2013/2/26 Frank Shearar <frank.shearar@gmail.com>:
On 26 February 2013 18:33, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
But it is true that GitHub is to SmalltakHub what npm/gem is to...?
No. GitHub and SmalltalkHub are repositories. Rubygems for Ruby (or clojars for Clojure, or CPAN for Perl) - are like SqueakMap - catalogs that point to packages/applications.
That's exactly what I said, that GitHub and SmalltalkHub are analogous. But we also need something like rubygems or npm or CPAN. I never used SqueakMap, so I can't tell. But if it is there, why is it not being used? Regards,
On 26 February 2013 19:06, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Hi Frank,
2013/2/26 Frank Shearar <frank.shearar@gmail.com>:
On 26 February 2013 18:33, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
But it is true that GitHub is to SmalltakHub what npm/gem is to...?
No. GitHub and SmalltalkHub are repositories. Rubygems for Ruby (or clojars for Clojure, or CPAN for Perl) - are like SqueakMap - catalogs that point to packages/applications.
That's exactly what I said, that GitHub and SmalltalkHub are analogous. But we also need something like rubygems or npm or CPAN.
I never used SqueakMap, so I can't tell. But if it is there, why is it not being used?
That's an excellent question, and one that Chris Muller and I would love an answer to. Partly it's because it's old and crufty. It could do with a rewrite, to be honest. But the idea is sound - the one place to go to find packages - and it works _today_. frank
On Tue, Feb 26, 2013 at 7:43 PM, Frank Shearar <frank.shearar@gmail.com> wrote:
On 26 February 2013 18:33, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2013/2/26 Marcus Denker <marcus.denker@inria.fr>:
On Feb 26, 2013, at 5:33 PM, "Esteban A. Maringolo" <emaringolo@gmail.com> wrote:
If you count the number of packages in SmalltalkHub and compare them to the ones in Npmjs.org, it is impressive how much we have. But isn't "package" more like "repository" on smalltalkhub?
It is a Project, but on the explore screen it says Packages, so... who knows? :)
But it is true that GitHub is to SmalltakHub what npm/gem is to...?
No. GitHub and SmalltalkHub are repositories. Rubygems for Ruby (or clojars for Clojure, or CPAN for Perl) - are like SqueakMap - catalogs that point to packages/applications.
IHMO, we don't need SqueakMap anymore. If we have ConfigurationOfXXX packages for each project and a different repositories for each Pharo distribution (like the one we have already in SqueakSource), I guess we are very close to the service proposed by SqueakMap. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://doesnotunderstand.org/
On 27 February 2013 07:51, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Tue, Feb 26, 2013 at 7:43 PM, Frank Shearar <frank.shearar@gmail.com> wrote:
On 26 February 2013 18:33, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2013/2/26 Marcus Denker <marcus.denker@inria.fr>:
On Feb 26, 2013, at 5:33 PM, "Esteban A. Maringolo" <emaringolo@gmail.com> wrote:
If you count the number of packages in SmalltalkHub and compare them to the ones in Npmjs.org, it is impressive how much we have. But isn't "package" more like "repository" on smalltalkhub?
It is a Project, but on the explore screen it says Packages, so... who knows? :)
But it is true that GitHub is to SmalltakHub what npm/gem is to...?
No. GitHub and SmalltalkHub are repositories. Rubygems for Ruby (or clojars for Clojure, or CPAN for Perl) - are like SqueakMap - catalogs that point to packages/applications.
IHMO, we don't need SqueakMap anymore. If we have ConfigurationOfXXX packages for each project and a different repositories for each Pharo distribution (like the one we have already in SqueakSource), I guess we are very close to the service proposed by SqueakMap.
Sure, see Stef's and my recent exchange. I guess when I say "SqueakMap" I should say "SM-like". I don't necessarily mean using the existing SM, although it's perfectly usable (despite the rather aged web UI) - Chris Muller and I nag people into adding their packages to the catalog on a regular basis - but Stef wants something like what SM provides only in an assured fashion - "this package definitely works with this version because we tried it". frank
Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://doesnotunderstand.org/
On Feb 27, 2013, at 9:20 AM, Frank Shearar <frank.shearar@gmail.com> wrote:
On 27 February 2013 07:51, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Tue, Feb 26, 2013 at 7:43 PM, Frank Shearar <frank.shearar@gmail.com> wrote:
On 26 February 2013 18:33, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2013/2/26 Marcus Denker <marcus.denker@inria.fr>:
On Feb 26, 2013, at 5:33 PM, "Esteban A. Maringolo" <emaringolo@gmail.com> wrote:
If you count the number of packages in SmalltalkHub and compare them to the ones in Npmjs.org, it is impressive how much we have. But isn't "package" more like "repository" on smalltalkhub?
It is a Project, but on the explore screen it says Packages, so... who knows? :)
But it is true that GitHub is to SmalltakHub what npm/gem is to...?
No. GitHub and SmalltalkHub are repositories. Rubygems for Ruby (or clojars for Clojure, or CPAN for Perl) - are like SqueakMap - catalogs that point to packages/applications.
IHMO, we don't need SqueakMap anymore. If we have ConfigurationOfXXX packages for each project and a different repositories for each Pharo distribution (like the one we have already in SqueakSource), I guess we are very close to the service proposed by SqueakMap.
Sure, see Stef's and my recent exchange. I guess when I say "SqueakMap" I should say "SM-like". I don't necessarily mean using the existing SM, although it's perfectly usable (despite the rather aged web UI) - Chris Muller and I nag people into adding their packages to the catalog on a regular basis - but Stef wants something like what SM provides only in an assured fashion - "this package definitely works with this version because we tried it".
Did you solve the problem that it was wasting ca. 4MB if memory because it had a copy of the complete catalog (everything but the files) on the client? Marcus
On 27 February 2013 08:26, Marcus Denker <marcus.denker@inria.fr> wrote:
On Feb 27, 2013, at 9:20 AM, Frank Shearar <frank.shearar@gmail.com> wrote:
On 27 February 2013 07:51, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Tue, Feb 26, 2013 at 7:43 PM, Frank Shearar <frank.shearar@gmail.com> wrote:
On 26 February 2013 18:33, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2013/2/26 Marcus Denker <marcus.denker@inria.fr>:
On Feb 26, 2013, at 5:33 PM, "Esteban A. Maringolo" <emaringolo@gmail.com> wrote:
If you count the number of packages in SmalltalkHub and compare them to the ones in Npmjs.org, it is impressive how much we have. But isn't "package" more like "repository" on smalltalkhub?
It is a Project, but on the explore screen it says Packages, so... who knows? :)
But it is true that GitHub is to SmalltakHub what npm/gem is to...?
No. GitHub and SmalltalkHub are repositories. Rubygems for Ruby (or clojars for Clojure, or CPAN for Perl) - are like SqueakMap - catalogs that point to packages/applications.
IHMO, we don't need SqueakMap anymore. If we have ConfigurationOfXXX packages for each project and a different repositories for each Pharo distribution (like the one we have already in SqueakSource), I guess we are very close to the service proposed by SqueakMap.
Sure, see Stef's and my recent exchange. I guess when I say "SqueakMap" I should say "SM-like". I don't necessarily mean using the existing SM, although it's perfectly usable (despite the rather aged web UI) - Chris Muller and I nag people into adding their packages to the catalog on a regular basis - but Stef wants something like what SM provides only in an assured fashion - "this package definitely works with this version because we tried it".
Did you solve the problem that it was wasting ca. 4MB if memory because it had a copy of the complete catalog (everything but the files) on the client?
It would appear so: SM takes up 296kB at the moment, according to SpaceTally.
Marcus
There is no magic if as a programmer we do not define the dependencies we cannot do anything. ;) so we should define configurationOf and we will take real advantages of them. Now if you read the vision document you will see what we want: we want a distribution that will be filled up automatically by executing configurations that are published in an inbox and validated (tests run, SmallLint rules run). Then we will be able to have a one click install of projects that are certified to load in a given image. Stef PS: SqueakMap failed because you had no idea is the package would load in your image. Believe me I know why I want the distribution infrastructure. On Feb 26, 2013, at 7:33 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2013/2/26 Marcus Denker <marcus.denker@inria.fr>:
On Feb 26, 2013, at 5:33 PM, "Esteban A. Maringolo" <emaringolo@gmail.com> wrote:
If you count the number of packages in SmalltalkHub and compare them to the ones in Npmjs.org, it is impressive how much we have. But isn't "package" more like "repository" on smalltalkhub?
It is a Project, but on the explore screen it says Packages, so... who knows? :)
But it is true that GitHub is to SmalltakHub what npm/gem is to...?
Of course NPM's user base is two orders of magnitude greater, but we need to start having more killer app "modules", and some sort of guideline for those starting with Pharo and/or Smalltalk. And we need a system in the first place like that⦠smalltalkhub is more for code repositories, not in itself a repository of installable entities.
Yes, having packages as "artifacts" is more straightforward than the configurations and all that jazz.
The MetaRepo is going in that direction, but I still think that evaluating the install statements with Gofer or anything similar in a Workspace is somehow alien for a non smalltalker.
There should be something that wraps Gofer and works like the apt, npm or gem commands.
So there is a lot of work ahead⦠but we will get there.
No doubts of that.
Regards!
On 26 February 2013 20:07, stephane ducasse <stephane.ducasse@free.fr> wrote:
There is no magic if as a programmer we do not define the dependencies we cannot do anything. ;) so we should define configurationOf and we will take real advantages of them.
Now if you read the vision document you will see what we want:
we want a distribution that will be filled up automatically by executing configurations that are published in an inbox and validated (tests run, SmallLint rules run).
Then we will be able to have a one click install of projects that are certified to load in a given image.
Stef PS: SqueakMap failed because you had no idea is the package would load in your image. Believe me I know why I want the distribution infrastructure.
Oh, did you mean to type "you had no idea IF the package would load"? OK, sure, but that's not really SM's fault, that's just the way things were. Nowadays with CI and all sorts of stuff we're (Pharo _and_ Squeak, I mean) in a much better place. There's still the modularity aspect to worry about in the general case, but CI can still help out a bit there, flushing out incompatible monkey patches. frank
On Feb 26, 2013, at 7:33 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2013/2/26 Marcus Denker <marcus.denker@inria.fr>:
On Feb 26, 2013, at 5:33 PM, "Esteban A. Maringolo" <emaringolo@gmail.com> wrote:
If you count the number of packages in SmalltalkHub and compare them to the ones in Npmjs.org, it is impressive how much we have. But isn't "package" more like "repository" on smalltalkhub?
It is a Project, but on the explore screen it says Packages, so... who knows? :)
But it is true that GitHub is to SmalltakHub what npm/gem is to...?
Of course NPM's user base is two orders of magnitude greater, but we need to start having more killer app "modules", and some sort of guideline for those starting with Pharo and/or Smalltalk. And we need a system in the first place like that⦠smalltalkhub is more for code repositories, not in itself a repository of installable entities.
Yes, having packages as "artifacts" is more straightforward than the configurations and all that jazz.
The MetaRepo is going in that direction, but I still think that evaluating the install statements with Gofer or anything similar in a Workspace is somehow alien for a non smalltalker.
There should be something that wraps Gofer and works like the apt, npm or gem commands.
So there is a lot of work ahead⦠but we will get there.
No doubts of that.
Regards!
2013/2/26 Frank Shearar <frank.shearar@gmail.com>:
On 26 February 2013 20:07, stephane ducasse <stephane.ducasse@free.fr> wrote:
There is no magic if as a programmer we do not define the dependencies we cannot do anything. ;) so we should define configurationOf and we will take real advantages of them.
Nowadays with CI and all sorts of stuff we're (Pharo _and_ Squeak, I mean) in a much better place. There's still the modularity aspect to worry about in the general case, but CI can still help out a bit there, flushing out incompatible monkey patches.
But the thing still is how to manage the dependencies without screwing the whole image. And so far, as Stephane said, the ConfigurationOf* is the only "safe" (and viable?) way to do it. Dependency management is not a simple problem, but succeeding at it would be a key differentiator. Regards,
On 26 February 2013 20:48, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2013/2/26 Frank Shearar <frank.shearar@gmail.com>:
On 26 February 2013 20:07, stephane ducasse <stephane.ducasse@free.fr> wrote:
There is no magic if as a programmer we do not define the dependencies we cannot do anything. ;) so we should define configurationOf and we will take real advantages of them.
Nowadays with CI and all sorts of stuff we're (Pharo _and_ Squeak, I mean) in a much better place. There's still the modularity aspect to worry about in the general case, but CI can still help out a bit there, flushing out incompatible monkey patches.
But the thing still is how to manage the dependencies without screwing the whole image. And so far, as Stephane said, the ConfigurationOf* is the only "safe" (and viable?) way to do it.
Dependency management is not a simple problem, but succeeding at it would be a key differentiator.
I know. You're right. I'm not saying anything different. Well, except for the differentiator part. The problem's pretty much solved in quite a few other languages. (Clojars can do this: https://clojars.org/cloverage. Rubygems doesn't, but it could, thanks to bundler.) SqueakMap's sole purpose is this: how do you FIND the ConfigurationOf? How do you know who to contact? What's the thing for, in the first place? And I'd argue that ss3 is not that catalog. (And that's before we talk about availability of services.) frank
Oh, did you mean to type "you had no idea IF the package would load"?
and work.
OK, sure, but that's not really SM's fault, that's just the way things were.
Nowadays with CI and all sorts of stuff we're (Pharo _and_ Squeak, I mean) in a much better place. There's still the modularity aspect to worry about in the general case, but CI can still help out a bit there, flushing out incompatible monkey patches.
If you want to use SqueakMap go ahead. I have been there and now I know what I want for Pharo. Stef
On 26 February 2013 20:55, stephane ducasse <stephane.ducasse@free.fr> wrote:
Oh, did you mean to type "you had no idea IF the package would load"?
and work.
OK, sure, but that's not really SM's fault, that's just the way things were.
Nowadays with CI and all sorts of stuff we're (Pharo _and_ Squeak, I mean) in a much better place. There's still the modularity aspect to worry about in the general case, but CI can still help out a bit there, flushing out incompatible monkey patches.
If you want to use SqueakMap go ahead. I have been there and now I know what I want for Pharo.
I never know what you mean when you say things like this. What is it that you want for Pharo?
Stef
If you want to use SqueakMap go ahead. I have been there and now I know what I want for Pharo.
Hi frank
I never know what you mean when you say things like this. What is it that you want for Pharo?
I wrote a 40 page vision document just for that. It was not really fun but this is an important document so that people that are not close to us can understand why we are doing certain things or saying others. So please have a look and let us know if this is clear. http://www.pharo-project.org/community/consortium A nice note: I browsed it 3 min and this is cool to see that some parts have already been done. The cool aspects is that I'm quite confident that we will implement the vision and do a lot more. Now to reply to your question is a bad three line (the full answer is nicely explained in the vision doc): I want an automated validated tested distributions and core system. I want that users can click on a package and that it loads and all the tests are green and the smallLint rule ok. I think that this is a minimum. And I do not want to rely on servers that can disappear. Stef
On 26 February 2013 21:26, stephane ducasse <stephane.ducasse@free.fr> wrote:
If you want to use SqueakMap go ahead. I have been there and now I know what I want for Pharo.
Hi frank
I never know what you mean when you say things like this. What is it that you want for Pharo?
I wrote a 40 page vision document just for that. It was not really fun but this is an important document so that people that are not close to us can understand why we are doing certain things or saying others. So please have a look and let us know if this is clear. http://www.pharo-project.org/community/consortium
Yes. I should have said "What is it that you want for Pharo, _in this case_?" I understand (and support) the Pharo vision in general, but I'm not clear on what you mean by "I have been there and now I know what I want for Pharo." I mean, SqueakMap is abysmally ugly, hard to navigate, etc. etc. And yet, the core idea is sound: a place that lets you find cool packages.
A nice note: I browsed it 3 min and this is cool to see that some parts have already been done. The cool aspects is that I'm quite confident that we will implement the vision and do a lot more.
Now to reply to your question is a bad three line (the full answer is nicely explained in the vision doc): I want an automated validated tested distributions and core system. I want that users can click on a package and that it loads and all the tests are green and the smallLint rule ok. I think that this is a minimum. And I do not want to rely on servers that can disappear.
I tell what _would_ be cool: something that does what SM does - lists available packages, tells you what Smalltalks those packages claim to support... and also automatically tells you the dependencies (easily doable thanks to Metacello) and - most importantly - _periodically verifies_ the claims. So you go to the site and it says "PetitParser runs on Pharo 1.4, 2.0, Squeak 4.4, 4.5 and Cuis 4.1" Wouldn't it be really cool if SM-like thing actually verified these claims? (It would have to farm out the task elsewhere, of course.) Actually, GitHub almost does all of what we need: it's searchable, and you can easily hook things like Travis CI to show that your project works. (But of course Travis CI is inadequate for the kinds of cross-platform stuff we typically write.) frank
Stef
Frank if you want me to continue to interact with you on this topic (which I hope) :) you will have to read the document :) Read it it takes 10 min on this point and you will see what we are starting to do. I wrote it specifically to document this kind of discussion but I will not reproduce it in emails :) We hope to have a first beta for June and it will be Cool and once it will be there nobody will not want to use it. I'm writing other chapters for the new book and this is an important task. Even if it is somehow boring too :). Syeg
Yes. I should have said "What is it that you want for Pharo, _in this case_?" I understand (and support) the Pharo vision in general, but I'm not clear on what you mean by "I have been there and now I know what I want for Pharo."
I mean, SqueakMap is abysmally ugly, hard to navigate, etc. etc. And yet, the core idea is sound: a place that lets you find cool packages.
A nice note: I browsed it 3 min and this is cool to see that some parts have already been done. The cool aspects is that I'm quite confident that we will implement the vision and do a lot more.
Now to reply to your question is a bad three line (the full answer is nicely explained in the vision doc): I want an automated validated tested distributions and core system. I want that users can click on a package and that it loads and all the tests are green and the smallLint rule ok. I think that this is a minimum. And I do not want to rely on servers that can disappear.
I tell what _would_ be cool: something that does what SM does - lists available packages, tells you what Smalltalks those packages claim to support... and also automatically tells you the dependencies (easily doable thanks to Metacello) and - most importantly - _periodically verifies_ the claims. So you go to the site and it says "PetitParser runs on Pharo 1.4, 2.0, Squeak 4.4, 4.5 and Cuis 4.1" Wouldn't it be really cool if SM-like thing actually verified these claims? (It would have to farm out the task elsewhere, of course.)
Actually, GitHub almost does all of what we need: it's searchable, and you can easily hook things like Travis CI to show that your project works. (But of course Travis CI is inadequate for the kinds of cross-platform stuff we typically write.)
frank
Stef
On 26 February 2013 22:15, stephane ducasse <stephane.ducasse@free.fr> wrote:
Frank
if you want me to continue to interact with you on this topic (which I hope) :) you will have to read the document :) Read it it takes 10 min on this point and you will see what we are starting to do. I wrote it specifically to document this kind of discussion but I will not reproduce it in emails :)
Sure, section 3.2. OK, so you're going to do what I'd just imagined. The SM-like thing just acts as a web UI to the various Distribution boxes. Cool! frank
We hope to have a first beta for June and it will be Cool and once it will be there nobody will not want to use it.
I'm writing other chapters for the new book and this is an important task. Even if it is somehow boring too :).
Syeg
Yes. I should have said "What is it that you want for Pharo, _in this case_?" I understand (and support) the Pharo vision in general, but I'm not clear on what you mean by "I have been there and now I know what I want for Pharo."
I mean, SqueakMap is abysmally ugly, hard to navigate, etc. etc. And yet, the core idea is sound: a place that lets you find cool packages.
A nice note: I browsed it 3 min and this is cool to see that some parts have already been done. The cool aspects is that I'm quite confident that we will implement the vision and do a lot more.
Now to reply to your question is a bad three line (the full answer is nicely explained in the vision doc): I want an automated validated tested distributions and core system. I want that users can click on a package and that it loads and all the tests are green and the smallLint rule ok. I think that this is a minimum. And I do not want to rely on servers that can disappear.
I tell what _would_ be cool: something that does what SM does - lists available packages, tells you what Smalltalks those packages claim to support... and also automatically tells you the dependencies (easily doable thanks to Metacello) and - most importantly - _periodically verifies_ the claims. So you go to the site and it says "PetitParser runs on Pharo 1.4, 2.0, Squeak 4.4, 4.5 and Cuis 4.1" Wouldn't it be really cool if SM-like thing actually verified these claims? (It would have to farm out the task elsewhere, of course.)
Actually, GitHub almost does all of what we need: it's searchable, and you can easily hook things like Travis CI to show that your project works. (But of course Travis CI is inadequate for the kinds of cross-platform stuff we typically write.)
frank
Stef
I like a lot this prediction and we will see that it will start to happen in Pharo3.0 Stef On Feb 26, 2013, at 5:18 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On Feb 26, 2013, at 4:57 PM, stephane ducasse <stephane.ducasse@free.fr> wrote:
I love the complete ecosystem you are step by step building. This is so great!
Yes! Just imagine we continue like that⦠we are now (slowly, slowly) reaching a point where for the first time we can really build on top of the foundation we did.
One central idea behind Pharo was to so we can do better on top of what we did. The effect we will get from that will be very interesting. Until now we have seen almost nothing, but now we are entering a phase where the difference will be not very pronounced but visible if you look for it.
Reflective improvement, leading to a feedback loop⦠and thus non-linear effects. I know that some people are laughing about this, but I really believe in it :-)
Marcus
On 26 Feb 2013, at 17:18, Marcus Denker <marcus.denker@inria.fr> wrote:
On Feb 26, 2013, at 4:57 PM, stephane ducasse <stephane.ducasse@free.fr> wrote:
I love the complete ecosystem you are step by step building. This is so great!
Yes! Just imagine we continue like that⦠we are now (slowly, slowly) reaching a point where for the first time we can really build on top of the foundation we did.
One central idea behind Pharo was to so we can do better on top of what we did. The effect we will get from that will be very interesting. Until now we have seen almost nothing, but now we are entering a phase where the difference will be not very pronounced but visible if you look for it.
Reflective improvement, leading to a feedback loop⦠and thus non-linear effects. I know that some people are laughing about this, but I really believe in it :-)
Marcus
Yes, that is certainly true. But there is not only a technical feedback loop with non linear effects, there is also a human and community reinforcement and accelleration going on that is really, really impressive. There are so many sub projects in/on Pharo, actually way too many to enumerate. They each directly or indirectly help or facilitate the others, spreading knowledge, creating Smalltalkers all over the world doing amazing stuff on the same base system. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
participants (6)
-
Esteban A. Maringolo -
Frank Shearar -
Marcus Denker -
Serge Stinckwich -
stephane ducasse -
Sven Van Caekenberghe