April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Let's get rid of Core vs. Full

by StÃ©phane Ducasse

This is my ideas. > My proposition for 1.3: > 1) Add MetacelloBrowser and switch to version-separated repositories (like MetaRepoForPharo11, etc. -I don't like the "abbreviated names" but you get the idea) > 2) Reduce the "full" image to Core+OB+RB+Shout+OCompletion+Finder+MetacelloBrowser > 3) If it is possible, develop Core image into this reduced full image.

April 4, 2011

Re: [Pharo-project] Transcript rant

by StÃ©phane Ducasse

> >>> +1 for both of Igor's mails! >> Why? this is really important to have threadsafe transcript and it is good to have a look at >> what juan did. >> >> We should be able to use a transcript even without morph. > It's that exactly what Igor was fighting for? ah ok this was totally unclear. Stef >> Stef >> >> >>> On 04/04/2011 03:11 PM, Igor Stasenko wrote: >>>> On 4 April 2011 14:46, Fernando Olivero<fernando.olivero(a)usi.ch> wrote: >>>>> Transcript could be polymorphic with a Stream, not necessarily a >>>>> subclass. Lets identify the methods that are missing and add them. For >>>>> instance, existing methods are: Transcript class>> nextPutAll: >>>>> aString. >>>>> >>>> To my sense, its basic protocol should be write stream. And additional methods, >>>> like endEntry could be there for compatibility. >>>> >>>>> Transcript is the model. TranscriptMorph is the view. Currently the >>>>> morph just displays a Form showing the model's contents. Wouldn't take >>>>> much to alter to present a TextMorph ( read-only right?). >>>>> >>>> Why read only? Who cares? All that view needs is to append a new entry >>>> to text morph once new content are coming in. >>>> If user wants to edit it or clear it later, let him do it. What user >>>> does is changing the text morph contents , but not transcript >>>> contents, >>>> because there is no such. An entry, once written to transcript, its gone. >>>> It should not preserve it if there is nobody listens for it. >>>> Why it should preserve all , what is written there, only to show on >>>> read-only morphic view? >>>> And how about selecting text? And how about clearing it? >>>> Should i clear it manually every time a stream size gets over multiple >>>> megabytes? >>>> >>>> It is wrong. A view is just a text morph, which appends new entries if >>>> new content comes in. >>>> If users wants to edit this morph or clear it, its not a problem, >>>> because user cannot edit stream contents.. there is no stream >>>> contents, >>>> because transcript stream is write-only stream. >>>> Which means if you don't capture what is written into it, then its >>>> gone and lost. >>>> >>>> A proper view for write only stream is just capture newly incoming >>>> content, but not read from some stream, >>>> because that implies that stream are readable and there are something >>>> which keeps its contents.. but its not. >>>> >>>> >>>>> Transcript behavior is in the class side because somehow its mimicking >>>>> a singleton, Transcript is still supposed to be unique in the image. >>>>> And thread safe, and enabling logging to file also. >>>>> >>>> What makes things thread safe? Thread safety means that nobody could >>>> access a state of object, >>>> when its in the middle of change operation. >>>> But since transcript is a write-only stream, there is no access to its >>>> state possible (you cannot read stuff which are written to it). >>>> You could just place a notifier which forwards what is written to it >>>> to some view.. >>>> And there is totally no need to maintain some internal state for >>>> transcript to access it later, and therefore its thread safe by >>>> default. >>>> >>>> >>>>> Fernando >>>>> >>>>> >>>>> On Mon, Apr 4, 2011 at 2:28 PM, Igor Stasenko<siguctua(a)gmail.com> wrote: >>>>>> It is broken, badly broken.. >>>>>> >>>>>> of course its a piece of cake to add #ensureCr method , so VMMaker >>>>>> will work properly.. >>>>>> but the problem is that Transcript from Cuis is even worse than we had before. >>>>>> >>>>>> First thing, is that Transcript is no longer a global variable, but >>>>>> instead a singleton class (Transcript). >>>>>> So, now, what i suppose to do if i want to redirect all >>>>>> Transcript show: ... >>>>>> to file instead of in-image stream? >>>>>> >>>>>> Second. I told it before and i will repeat it again. >>>>>> Transcript ===== WriteStream >>>>>> >>>>>> yes, it is stream. >>>>>> >>>>>> And Transcript as a tool - a window which you see on desktop is a >>>>>> view of that stream. Do you follow? Transcript is model, and >>>>>> transcript window is view. Simple enough? >>>>>> Then why its not like that? >>>>>> >>>>>> So, we should have a model, which is a stream, >>>>>> and as many as we like views, which simply listening of updates on >>>>>> that stream and updating their view correspondingly.. >>>>>> >>>>>> This means that to do it right, we should do something like following: >>>>>> >>>>>> - Transcript is a stream, but which also notifies the view(s) about >>>>>> new stuff coming in, so views can react and update themselves >>>>>> - Transcript is write only stream, and any attempts to seek or read >>>>>> from it should be prohibited. Sorry guys.. if i'd like to do >>>>>> transcript logging via socket, >>>>>> where i suppose to take a content which i already sent via wire? >>>>>> >>>>>> it would be really nice to have xtreams, which allow stream >>>>>> composition.. so then transcript is a composed stream of a following >>>>>> form: >>>>>> >>>>>> notifier stream -> output stream >>>>>> >>>>>> notifier stream is direct any writes to output stream, but in addition >>>>>> it notifies any listeners about new content are written to it. This is >>>>>> easy to implement using xtreams.. >>>>>> but not so easy with old streams (but its doable). >>>>>> An output stream could be anything, which application/image wants to be. >>>>>> For obvious reasons, i'd like to redirect all transcript output in >>>>>> headless mode to stdout. It was doable with old implementation.. but >>>>>> with a new one its impossible, because then i will need to replace >>>>>> class with something else, >>>>>> and then restore it back when i have to switch back to normal operation... >>>>>> >>>>>> >>>>>> Views.. Views are receiving notifications and update their own >>>>>> contents (usually text morphs). There could be as many as one wants >>>>>> views on transcript stream. Not only one. >>>>>> I really don't like that in new transcript i can't even select a text >>>>>> or clear window... from my POV this is what called regression. >>>>>> >>>>>> Make it simple, but not simpler (c) Albert Einstein. >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>>> >>>> >>> >> > >

April 4, 2011

Re: [Pharo-project] Transcript rant

by StÃ©phane Ducasse

Hi igor I would like to try to understand and be more in positive thinking mode. > First thing, is that Transcript is no longer a global variable, but > instead a singleton class (Transcript). > So, now, what i suppose to do if i want to redirect all > Transcript show: ... > to file instead of in-image stream? so does what fernando replied true? In that case it does not look as a problem > Second. I told it before and i will repeat it again. > Transcript ===== WriteStream > > yes, it is stream. > > And Transcript as a tool - a window which you see on desktop is a > view of that stream. Do you follow? Transcript is model, and > transcript window is view. Simple enough? > Then why its not like that? What is the implication at the design and use level of Transcript been a stream? > So, we should have a model, which is a stream, > and as many as we like views, which simply listening of updates on > that stream and updating their view correspondingly.. > > This means that to do it right, we should do something like following: > > - Transcript is a stream, but which also notifies the view(s) about > new stuff coming in, so views can react and update themselves > - Transcript is write only stream, and any attempts to seek or read > from it should be prohibited. Sorry guys.. if i'd like to do > transcript logging via socket, > where i suppose to take a content which i already sent via wire? you lost me here. > it would be really nice to have xtreams, which allow stream > composition.. so then transcript is a composed stream of a following > form: > > notifier stream -> output stream > > notifier stream is direct any writes to output stream, but in addition > it notifies any listeners about new content are written to it. This is > easy to implement using xtreams.. > but not so easy with old streams (but its doable). > An output stream could be anything, which application/image wants to be. > For obvious reasons, i'd like to redirect all transcript output in > headless mode to stdout. It was doable with old implementation.. but > with a new one its impossible, because then i will need to replace > class with something else, > and then restore it back when i have to switch back to normal operation... Really? > Views.. Views are receiving notifications and update their own > contents (usually text morphs). There could be as many as one wants > views on transcript stream. Not only one. > I really don't like that in new transcript i can't even select a text > or clear window... from my POV this is what called regression. We can revert it if this is important Now let us try to learn. Stef > > Make it simple, but not simpler (c) Albert Einstein. > > -- > Best regards, > Igor Stasenko AKA sig. >

April 4, 2011

Re: [Pharo-project] Transcript rant

by Toon Verwaest

On 04/04/2011 03:50 PM, StÃ©phane Ducasse wrote: >> +1 for both of Igor's mails! > Why? this is really important to have threadsafe transcript and it is good to have a look at > what juan did. > > We should be able to use a transcript even without morph. It's that exactly what Igor was fighting for? > Stef > > >> On 04/04/2011 03:11 PM, Igor Stasenko wrote: >>> On 4 April 2011 14:46, Fernando Olivero<fernando.olivero(a)usi.ch> wrote: >>>> Transcript could be polymorphic with a Stream, not necessarily a >>>> subclass. Lets identify the methods that are missing and add them. For >>>> instance, existing methods are: Transcript class>> nextPutAll: >>>> aString. >>>> >>> To my sense, its basic protocol should be write stream. And additional methods, >>> like endEntry could be there for compatibility. >>> >>>> Transcript is the model. TranscriptMorph is the view. Currently the >>>> morph just displays a Form showing the model's contents. Wouldn't take >>>> much to alter to present a TextMorph ( read-only right?). >>>> >>> Why read only? Who cares? All that view needs is to append a new entry >>> to text morph once new content are coming in. >>> If user wants to edit it or clear it later, let him do it. What user >>> does is changing the text morph contents , but not transcript >>> contents, >>> because there is no such. An entry, once written to transcript, its gone. >>> It should not preserve it if there is nobody listens for it. >>> Why it should preserve all , what is written there, only to show on >>> read-only morphic view? >>> And how about selecting text? And how about clearing it? >>> Should i clear it manually every time a stream size gets over multiple >>> megabytes? >>> >>> It is wrong. A view is just a text morph, which appends new entries if >>> new content comes in. >>> If users wants to edit this morph or clear it, its not a problem, >>> because user cannot edit stream contents.. there is no stream >>> contents, >>> because transcript stream is write-only stream. >>> Which means if you don't capture what is written into it, then its >>> gone and lost. >>> >>> A proper view for write only stream is just capture newly incoming >>> content, but not read from some stream, >>> because that implies that stream are readable and there are something >>> which keeps its contents.. but its not. >>> >>> >>>> Transcript behavior is in the class side because somehow its mimicking >>>> a singleton, Transcript is still supposed to be unique in the image. >>>> And thread safe, and enabling logging to file also. >>>> >>> What makes things thread safe? Thread safety means that nobody could >>> access a state of object, >>> when its in the middle of change operation. >>> But since transcript is a write-only stream, there is no access to its >>> state possible (you cannot read stuff which are written to it). >>> You could just place a notifier which forwards what is written to it >>> to some view.. >>> And there is totally no need to maintain some internal state for >>> transcript to access it later, and therefore its thread safe by >>> default. >>> >>> >>>> Fernando >>>> >>>> >>>> On Mon, Apr 4, 2011 at 2:28 PM, Igor Stasenko<siguctua(a)gmail.com> wrote: >>>>> It is broken, badly broken.. >>>>> >>>>> of course its a piece of cake to add #ensureCr method , so VMMaker >>>>> will work properly.. >>>>> but the problem is that Transcript from Cuis is even worse than we had before. >>>>> >>>>> First thing, is that Transcript is no longer a global variable, but >>>>> instead a singleton class (Transcript). >>>>> So, now, what i suppose to do if i want to redirect all >>>>> Transcript show: ... >>>>> to file instead of in-image stream? >>>>> >>>>> Second. I told it before and i will repeat it again. >>>>> Transcript ===== WriteStream >>>>> >>>>> yes, it is stream. >>>>> >>>>> And Transcript as a tool - a window which you see on desktop is a >>>>> view of that stream. Do you follow? Transcript is model, and >>>>> transcript window is view. Simple enough? >>>>> Then why its not like that? >>>>> >>>>> So, we should have a model, which is a stream, >>>>> and as many as we like views, which simply listening of updates on >>>>> that stream and updating their view correspondingly.. >>>>> >>>>> This means that to do it right, we should do something like following: >>>>> >>>>> - Transcript is a stream, but which also notifies the view(s) about >>>>> new stuff coming in, so views can react and update themselves >>>>> - Transcript is write only stream, and any attempts to seek or read >>>>> from it should be prohibited. Sorry guys.. if i'd like to do >>>>> transcript logging via socket, >>>>> where i suppose to take a content which i already sent via wire? >>>>> >>>>> it would be really nice to have xtreams, which allow stream >>>>> composition.. so then transcript is a composed stream of a following >>>>> form: >>>>> >>>>> notifier stream -> output stream >>>>> >>>>> notifier stream is direct any writes to output stream, but in addition >>>>> it notifies any listeners about new content are written to it. This is >>>>> easy to implement using xtreams.. >>>>> but not so easy with old streams (but its doable). >>>>> An output stream could be anything, which application/image wants to be. >>>>> For obvious reasons, i'd like to redirect all transcript output in >>>>> headless mode to stdout. It was doable with old implementation.. but >>>>> with a new one its impossible, because then i will need to replace >>>>> class with something else, >>>>> and then restore it back when i have to switch back to normal operation... >>>>> >>>>> >>>>> Views.. Views are receiving notifications and update their own >>>>> contents (usually text morphs). There could be as many as one wants >>>>> views on transcript stream. Not only one. >>>>> I really don't like that in new transcript i can't even select a text >>>>> or clear window... from my POV this is what called regression. >>>>> >>>>> Make it simple, but not simpler (c) Albert Einstein. >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> >>> >> >

April 4, 2011

Re: [Pharo-project] Transcript rant

by StÃ©phane Ducasse

> +1 for both of Igor's mails! Why? this is really important to have threadsafe transcript and it is good to have a look at what juan did. We should be able to use a transcript even without morph. Stef > On 04/04/2011 03:11 PM, Igor Stasenko wrote: >> On 4 April 2011 14:46, Fernando Olivero<fernando.olivero(a)usi.ch> wrote: >>> Transcript could be polymorphic with a Stream, not necessarily a >>> subclass. Lets identify the methods that are missing and add them. For >>> instance, existing methods are: Transcript class>> nextPutAll: >>> aString. >>> >> To my sense, its basic protocol should be write stream. And additional methods, >> like endEntry could be there for compatibility. >> >>> Transcript is the model. TranscriptMorph is the view. Currently the >>> morph just displays a Form showing the model's contents. Wouldn't take >>> much to alter to present a TextMorph ( read-only right?). >>> >> Why read only? Who cares? All that view needs is to append a new entry >> to text morph once new content are coming in. >> If user wants to edit it or clear it later, let him do it. What user >> does is changing the text morph contents , but not transcript >> contents, >> because there is no such. An entry, once written to transcript, its gone. >> It should not preserve it if there is nobody listens for it. >> Why it should preserve all , what is written there, only to show on >> read-only morphic view? >> And how about selecting text? And how about clearing it? >> Should i clear it manually every time a stream size gets over multiple >> megabytes? >> >> It is wrong. A view is just a text morph, which appends new entries if >> new content comes in. >> If users wants to edit this morph or clear it, its not a problem, >> because user cannot edit stream contents.. there is no stream >> contents, >> because transcript stream is write-only stream. >> Which means if you don't capture what is written into it, then its >> gone and lost. >> >> A proper view for write only stream is just capture newly incoming >> content, but not read from some stream, >> because that implies that stream are readable and there are something >> which keeps its contents.. but its not. >> >> >>> Transcript behavior is in the class side because somehow its mimicking >>> a singleton, Transcript is still supposed to be unique in the image. >>> And thread safe, and enabling logging to file also. >>> >> What makes things thread safe? Thread safety means that nobody could >> access a state of object, >> when its in the middle of change operation. >> But since transcript is a write-only stream, there is no access to its >> state possible (you cannot read stuff which are written to it). >> You could just place a notifier which forwards what is written to it >> to some view.. >> And there is totally no need to maintain some internal state for >> transcript to access it later, and therefore its thread safe by >> default. >> >> >>> Fernando >>> >>> >>> On Mon, Apr 4, 2011 at 2:28 PM, Igor Stasenko<siguctua(a)gmail.com> wrote: >>>> It is broken, badly broken.. >>>> >>>> of course its a piece of cake to add #ensureCr method , so VMMaker >>>> will work properly.. >>>> but the problem is that Transcript from Cuis is even worse than we had before. >>>> >>>> First thing, is that Transcript is no longer a global variable, but >>>> instead a singleton class (Transcript). >>>> So, now, what i suppose to do if i want to redirect all >>>> Transcript show: ... >>>> to file instead of in-image stream? >>>> >>>> Second. I told it before and i will repeat it again. >>>> Transcript ===== WriteStream >>>> >>>> yes, it is stream. >>>> >>>> And Transcript as a tool - a window which you see on desktop is a >>>> view of that stream. Do you follow? Transcript is model, and >>>> transcript window is view. Simple enough? >>>> Then why its not like that? >>>> >>>> So, we should have a model, which is a stream, >>>> and as many as we like views, which simply listening of updates on >>>> that stream and updating their view correspondingly.. >>>> >>>> This means that to do it right, we should do something like following: >>>> >>>> - Transcript is a stream, but which also notifies the view(s) about >>>> new stuff coming in, so views can react and update themselves >>>> - Transcript is write only stream, and any attempts to seek or read >>>> from it should be prohibited. Sorry guys.. if i'd like to do >>>> transcript logging via socket, >>>> where i suppose to take a content which i already sent via wire? >>>> >>>> it would be really nice to have xtreams, which allow stream >>>> composition.. so then transcript is a composed stream of a following >>>> form: >>>> >>>> notifier stream -> output stream >>>> >>>> notifier stream is direct any writes to output stream, but in addition >>>> it notifies any listeners about new content are written to it. This is >>>> easy to implement using xtreams.. >>>> but not so easy with old streams (but its doable). >>>> An output stream could be anything, which application/image wants to be. >>>> For obvious reasons, i'd like to redirect all transcript output in >>>> headless mode to stdout. It was doable with old implementation.. but >>>> with a new one its impossible, because then i will need to replace >>>> class with something else, >>>> and then restore it back when i have to switch back to normal operation... >>>> >>>> >>>> Views.. Views are receiving notifications and update their own >>>> contents (usually text morphs). There could be as many as one wants >>>> views on transcript stream. Not only one. >>>> I really don't like that in new transcript i can't even select a text >>>> or clear window... from my POV this is what called regression. >>>> >>>> Make it simple, but not simpler (c) Albert Einstein. >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> >>> >> >> > >

April 4, 2011

Re: [Pharo-project] Transcript rant

by Toon Verwaest

+1 for both of Igor's mails! On 04/04/2011 03:11 PM, Igor Stasenko wrote: > On 4 April 2011 14:46, Fernando Olivero<fernando.olivero(a)usi.ch> wrote: >> Transcript could be polymorphic with a Stream, not necessarily a >> subclass. Lets identify the methods that are missing and add them. For >> instance, existing methods are: Transcript class>> nextPutAll: >> aString. >> > To my sense, its basic protocol should be write stream. And additional methods, > like endEntry could be there for compatibility. > >> Transcript is the model. TranscriptMorph is the view. Currently the >> morph just displays a Form showing the model's contents. Wouldn't take >> much to alter to present a TextMorph ( read-only right?). >> > Why read only? Who cares? All that view needs is to append a new entry > to text morph once new content are coming in. > If user wants to edit it or clear it later, let him do it. What user > does is changing the text morph contents , but not transcript > contents, > because there is no such. An entry, once written to transcript, its gone. > It should not preserve it if there is nobody listens for it. > Why it should preserve all , what is written there, only to show on > read-only morphic view? > And how about selecting text? And how about clearing it? > Should i clear it manually every time a stream size gets over multiple > megabytes? > > It is wrong. A view is just a text morph, which appends new entries if > new content comes in. > If users wants to edit this morph or clear it, its not a problem, > because user cannot edit stream contents.. there is no stream > contents, > because transcript stream is write-only stream. > Which means if you don't capture what is written into it, then its > gone and lost. > > A proper view for write only stream is just capture newly incoming > content, but not read from some stream, > because that implies that stream are readable and there are something > which keeps its contents.. but its not. > > >> Transcript behavior is in the class side because somehow its mimicking >> a singleton, Transcript is still supposed to be unique in the image. >> And thread safe, and enabling logging to file also. >> > What makes things thread safe? Thread safety means that nobody could > access a state of object, > when its in the middle of change operation. > But since transcript is a write-only stream, there is no access to its > state possible (you cannot read stuff which are written to it). > You could just place a notifier which forwards what is written to it > to some view.. > And there is totally no need to maintain some internal state for > transcript to access it later, and therefore its thread safe by > default. > > >> Fernando >> >> >> On Mon, Apr 4, 2011 at 2:28 PM, Igor Stasenko<siguctua(a)gmail.com> wrote: >>> It is broken, badly broken.. >>> >>> of course its a piece of cake to add #ensureCr method , so VMMaker >>> will work properly.. >>> but the problem is that Transcript from Cuis is even worse than we had before. >>> >>> First thing, is that Transcript is no longer a global variable, but >>> instead a singleton class (Transcript). >>> So, now, what i suppose to do if i want to redirect all >>> Transcript show: ... >>> to file instead of in-image stream? >>> >>> Second. I told it before and i will repeat it again. >>> Transcript ===== WriteStream >>> >>> yes, it is stream. >>> >>> And Transcript as a tool - a window which you see on desktop is a >>> view of that stream. Do you follow? Transcript is model, and >>> transcript window is view. Simple enough? >>> Then why its not like that? >>> >>> So, we should have a model, which is a stream, >>> and as many as we like views, which simply listening of updates on >>> that stream and updating their view correspondingly.. >>> >>> This means that to do it right, we should do something like following: >>> >>> - Transcript is a stream, but which also notifies the view(s) about >>> new stuff coming in, so views can react and update themselves >>> - Transcript is write only stream, and any attempts to seek or read >>> from it should be prohibited. Sorry guys.. if i'd like to do >>> transcript logging via socket, >>> where i suppose to take a content which i already sent via wire? >>> >>> it would be really nice to have xtreams, which allow stream >>> composition.. so then transcript is a composed stream of a following >>> form: >>> >>> notifier stream -> output stream >>> >>> notifier stream is direct any writes to output stream, but in addition >>> it notifies any listeners about new content are written to it. This is >>> easy to implement using xtreams.. >>> but not so easy with old streams (but its doable). >>> An output stream could be anything, which application/image wants to be. >>> For obvious reasons, i'd like to redirect all transcript output in >>> headless mode to stdout. It was doable with old implementation.. but >>> with a new one its impossible, because then i will need to replace >>> class with something else, >>> and then restore it back when i have to switch back to normal operation... >>> >>> >>> Views.. Views are receiving notifications and update their own >>> contents (usually text morphs). There could be as many as one wants >>> views on transcript stream. Not only one. >>> I really don't like that in new transcript i can't even select a text >>> or clear window... from my POV this is what called regression. >>> >>> Make it simple, but not simpler (c) Albert Einstein. >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> >> > >

April 4, 2011

Re: [Pharo-project] IPAddressCountry & Iso3166CountryLongitudeLatitude

by Henrik Johansen

But.... I thought the proper way to track IP adresses was to create a GUI interface in Visual Basic! Joke aside, really neat stuff :D Cheers, Henry PS. I take it you'd be interested in updating SmallInteger digitAt: / digitLength to work in 64bit images if they become available? ;) On Apr 4, 2011, at 3:21 09PM, Sven Van Caekenberghe wrote: > I want to share a couple of classes. > > Did you ever want to add this trick to your website where you do something based on the country your visitors are from ? Now you can do so in Smalltalk ! > > T3EasyUtils getIpAddressCountry atAddress: '81.83.7.35' > > #BE > > T3EasyUtils getIso3166CountryLongitudeLatitude at: #BE > > 4.0(a)50.8333 > > #('www.beta9.be' 'www.inria.fr' 'nic.st' 'www.world.st' 'www.pharo-project.org') > collect: [ :each | T3EasyUtils getIpAddressCountry atAddress: (NetNameResolver addressForName: each) ] > > #(#BE #FR #SE #US #CH) > > (T3EasyUtils is holding unique, loaded instances of IPAddressCountry & Iso3166CountryLongitudeLatitude). > > As this is part of one of our commercial applications, you can even access it over the internet as a JSON REST call: > > $ curl http://easy.t3-platform.net/rest/geo-ip?address=81.83.7.35 > > {"latitude":50.8333,"address":"81.83.7.35","country":"BE","longitude":4.0} > > (Please note that this is not a public service as such, you can try it, but you are not supposed to call this from your own applications.) > > BTW, T3 Easy is our new entry level track & trace product, an HTML5 web app (using client side HTML+Javascript+CSS) on top of a REST server written in Pharo Smalltalk. It consists of 4 stateless Pharo Cog VM's running behind an Apache load balancer. The server uses Zinc HTTP Components, both for its server part, as well as for clients talking to other systems behind the scenes. Even the Open Street Map tile serving, which is pushing out many megabytes, is currently going through this server. > > Here is a live demo URL in case your are curious: > > http://easy.t3-platform.net?t=livedemo > > (You need a fast web browser like Google Chrome, Safari, Opera 10 or Firefox 4.) > > The code for IPAddressCountry & Iso3166CountryLongitudeLatitude is on SqueakSource: > > http://www.squeaksource.com/ADayAtTheBeach.html > > These are the class comments: > > --- > > IPAddressCountry maps IP addresses to their country code. > I hold a collection of IPAddressRangeCountry objects that I do a binary search on. > > I am constructed based on a CSV data file using my class' #readFrom: > which expects lines like 3651886848,3651887103,BE or start,stop,code > > You can download a version of this file from http://homepage.mac.com/svc/data/GeoIPCountry.csv.gz > > ((IPAddressCountry readFrom: 'GeoIPCountry.csv') atAddress: '81.83.7.35') = #BE > > Addresses can also be specified as #(81 83 7 35) for #atAddress: or as 1364395811 for #at: > > You should cache one instance of me. > > Based on data from http://www.maxmind.com/app/geolitecountry > > --- > > Iso3166CountryLongitudeLatitude maps country codes to their average or central longtiude/latitude. > > My keys are two letter Iso3166 Symbols representing a country, such as #BE > My values are Points holding coordinates as longtiude@latitude > > I am constructed based on a CSV data file using my class' #readFrom: > which expects lines like BE,50.8333,4.0000 or code,latitude,longitude > > You can download a version of this file from http://homepage.mac.com/svc/data/CountryLatLong.csv.gz > > ((Iso3166CountryLongitudeLatitude readFrom: 'CountryLatLong.csv') at: #BE) = 4.0(a)50.8333 > > You should cache one instance of me. > > --- > > Sven > > >

April 4, 2011

Re: [Pharo-project] [ANN 1.2] 1.2.1 Full Release Image

by StÃ©phane Ducasse

Please help because we have not the steam for the splash organization. >> > Marcus et al, > > I have to agree with Laurent: you and the rest of Pharo are being way too modest here. Like most users I have been waiting for 1.2.x to be announced with a big splash. I know and understand how it has been a long and boring process at the end. > > Like you said, a release is just a release: a group of developers deciding that the current state of the system is 'good enough'. I have been using a #12333 hudson/jenkins built Seaside 3.0.3 image for more than a month for development and server deployment and it has been a very nice experience (in other words, it worked perfectly). > > So, from my part: thank you for all the efforts, the results are fantastic! > > So please, organize some kind of splash! > > Regards, > > Sven > > > >

April 4, 2011

Re: [Pharo-project] Pharo 1.3 process

by StÃ©phane Ducasse

second one. Yes I would like but no time. Stef On Apr 4, 2011, at 1:56 PM, Esteban Lorenzano wrote: > btw... how's the repository policy we are going to use? to keep MetacelloRepository? > or better to use MetacelloRepositoryForPharo12, etc.? > > if we are going for the 2nd option, we need to start switching :P > > cheers, > Esteban > > > El 03/04/2011, a las 4:17p.m., StÃ©phane Ducasse escribiÃ³: > >>> >>> - Get rid of the Core/Full image destinction. This does not work. And I will not do a release with having two images again... it never worked, and it will never work. >> >> Yes but for that we need a good browser that we can maintain. >> >>> Yes, 2 images seems hard to maintain and hard to understand for newcomers. >>> >>> May be we can have: >>> - Metacello configurations tested separately in Pharo-Clients in Hudson (like PetitParser, Seaside, ...) - drop the ones that don't have tests >>> - drop actual Pharo, rename PharoCore => Pharo. >>> - GUI tool in Pharo to easy load Metacello configurations (some stuff must be easy to load for newbies, especially help >> >> This is the idea. This is why I asked people (mariano in particular) to focus on helping metacello taking off the ground >> and to focus on metacello distributions. Once this is up and running. we can have Pharo and hudson loads and certifies the distributions. >> >> Stef > >

April 4, 2011

Re: [Pharo-project] Let's get rid of Core vs. Full

by Esteban Lorenzano

Hi, Well... I disagree to completely abandon full images. I understand the good reasons Marcus et all have to propose this, but in my opinion abandon a development image with needed development tools is a mistake, because most of us use it for development our applications, and most of newbies for sure need it, and don't know how to build it by themselves. Most of my students use the Pharo full image, and they tend to consider full images the real "Pharo" images (same way most people consider JSE version of eclipse the "real" eclipse). Said so... I really thing we need to flatten the pharo full image to it's minimal expression. I think now is some-kind over bloated and most of the problems we have is because we add too much packages to it, and for that reason we can't use it to develop the core image. My proposition for 1.3: 1) Add MetacelloBrowser and switch to version-separated repositories (like MetaRepoForPharo11, etc. -I don't like the "abbreviated names" but you get the idea) 2) Reduce the "full" image to Core+OB+RB+Shout+OCompletion+Finder+MetacelloBrowser 3) If it is possible, develop Core image into this reduced full image. Cheers, Esteban El 04/04/2011, a las 6:26a.m., Stuart Herring escribiÃ³: > On Mon, Apr 4, 2011 at 3:56 AM, Dale Henrichs <dhenrich(a)vmware.com> wrote: >> Rather than abandon core vs full, here's a thought on a slightly different approach... >> >> Do development in the FULL version. That way the tools are used and bugs in the tools are fixed as the changes are made in the CORE...you are keeping the FULL alive, not adding new features, etc, since that kind of work is the responsibility of the maintainers ... >> >> Use the build server to run tests against the CORE and the set of CORE tools... >> > This is what makes the most sense to me as a user - and one that uses > both core and dev. > Dev is what I spend 99% of my time in, and of course core is what I > actually deploy my applications on. But pretty much all of my > impression of Pharo comes from Dev. > > The worry I would have about having only core releases, or core + > untested Dev script would be that given the "clean design over > backward compatibility" philosophy, none of the development tools > would ever keep up with the changes in Core. You'd effectively have a > product that was unusable to a developer (or at least, not a fair > representation of how good Smalltalk can be for development). > > It basically comes down to this: > Either you want to provide developer tools with Pharo or you do not. > If you do not, then ditch Dev entirely, and make it very clear that > Pharo is just a platform, and the third party developers of > development tools will need to support Pharo specifically. > If you do, then the Development tools need to be first class citizens. > You need to develop in Dev - which is built from Core. And Dev needs > to benefit from the same sorts of refactorings and cleanings as Core > does, and tests in Dev must always be green (blue). > > Given that the webpage currently states that providing excellent > development tools is a primary goal of Pharo, I feel that Dale's > approach is what makes the most sense. > > Regards, > Stuart >

April 4, 2011