Pharo-users

By thread

pharo-users@lists.pharo.org

January 2018

82 participants
456 messages

Re: [Pharo-users] [ANN] Bittrex API

by HernÃ¡n Morales Durand

Hi Ben 2018-01-15 4:53 GMT-03:00 Ben Coman <btc(a)openinworld.com>: > On 15 January 2018 at 14:19, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com> wrote: >> Hi Ben, >> >> Thank you for sharing this, looks really cool. >> > > > >> I have some issues installing the library. In the "Clone repository" >> dialog I had to use >> >> https://github.com/Traadh/bittrex.git >> > > Which OS are you on? > For Windows you need to enable Iceberg > Settings > Custom keys > since Iceberg is not playing well there with ssh-agent. > Also, the software for creating ssh keys is not built into Windows. Try... > http://guides.beanstalkapp.com/version-control/git-on-windows.html > > > Have you previously accessed github via SSH keys from command line? > Check your SSH keys are configured properly... > https://help.github.com/articles/testing-your-ssh-connection/ > and if not, get that working first... > https://help.github.com/articles/connecting-to-github-with-ssh/ > Thanks, I am using Windows and actually I can use other repositories. Anyway I prefer to wait the Baseline :) > >> The install procedure did not downloaded the libsodium library. > > Whoops, missed that. I'll update the procedure. > Also its about time I write my first Baseline. > > >> I had to install it from loading Nacl. >> Any particular difference with Nacl? From the dll in Nacl I can see >> Bittrex functions are supported but appending a "256" in the function >> prototype, i.e.: crypto_auth_hmacsha512256_keybytes , >> maybe you can add the functions to the Nacl repository? >> http://www.smalltalkhub.com/#!/~tonyg/Crypto-Nacl > > I tried Crpto-Nacl first. This was my first time using Libsodium and > it was difficult to find examples directly on the > HMAC512 function I needed. The sample C code I compiled as a test > didn't match the function names > exported from Crypto-Nacl so this confounded my trials. It was simple > to FFI wrap the one Libsodium function I needed, > so thats what I did. Crypto-Nacl just provides the core operations, while sodium is a Nacl fork which includes extra functions, which honestly I never need but the library should work as well as they claim to be 100% compatible. > > The Configuration of Crypto-Nacl downloads a pre-compiled libsodium > that exports different symbols to the system libsodium. I didn't knew there was a system libsodium. I guess it is some lib that is included in you OS by default. > So IIUC its not a matter of just adding extra Smalltalk methods to the > Crypto-Nacl. > I don't know enough about Libsodium to understand the difference in > function naming > and I guess replacing it might break existing users ?? > I will have a look, can you provide a link to the libsodium library you are using? > >> Or you can use the URL's in ConfigurationOfNacl>>platformLibraryUrl to >> download the library for each platform, >> or integrate the download procedure in >> https://github.com/hernanmd/MetacelloFileDownload > > good idea. thx for the tip. > cheers -ben > > >> >> Cheers, >> >> HernÃ¡n >> >> >> >> >> >> >> 2018-01-13 16:07 GMT-03:00 Ben Coman <btc(a)openinworld.com>: >>> Thanks everyone who advised on Zinc, REST, NeoJSON, HMAC & Libsodium >>> to help me on my way to implement an interface to the Bittrex bitcoin >>> exchange. I've got to the point where I'm happy to make an initial >>> 0.x release. After all my years having fun hacking around Pharo, this >>> is my first (tiny) product. Hopefully it may grow. :) >>> >>> The implementation is probably closest to a Command pattern >>> with a class per entry-point. All the v1.1 entry points are >>> implemented except a few to deposit & withdraw money from the >>> exchange. These are currently infrequent events for me and left for >>> manual action. >>> >>> I'm optimistic that I'll add a few more exchanges so I created a >>> github org to group them together. Contributions welcome. >>> >>> Please see quick start instructions here... >>> https://github.com/Traadh/bittrex >>> >>> Have fun and take care... >>> https://imgs.xkcd.com/comics/engineer_syllogism.png >>> >>> cheers -ben >>> >> >

Jan. 16, 2018

Re: [Pharo-users] How to declare a do:[] loop for a matrix to read and acces its elements?

by Photon

So for those of you who are interested or maybe is struggeling himself. I did it now in a more C fashion if i can call it like that. I don`t know if its even legit :P I managed to make the game work based on this method, the rest was easy. At least enough for tonight. Tomorrow I try to add a nice U.I. still here is how I did it : I also wrote two tests. The first one is the test for the method itself and the second one is just to test an algorythm construction because the one i used before had an endless loop I quess. And : -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 16, 2018

Re: [Pharo-users] Pharo-users Digest, Vol 57, Issue 39

by Dale Henrichs

Ian, You are not being completely transparent .... My initial response[2] (on the8th of January) to your initial post on the tode mailing list[1] (from the 4th of January): I am wanting to use Gemstone as a persistent object store. I do not want it to run any client facing applications. I want to run all client facing applications in pharo images of there own connected to a central backing stone. Is this the wrong way to think about this? was to echo Petr Fischer's initial response[3] which was "Your best bet is to use REST" You continued to ask several questions about how GemStone actually works (calling it a backing store is not a fair characterization of GemStone) and I tried to fill in various additional details about other possible approaches since you didn't seem to be very clear about what you were interested in. It wasn't until the 11th that you wrote the nicely detailed post[4] about intentions to use Amber and GemStone and a RESTful API for your application that involves petabytes of data. And then this morning you decided to post some non-flattering comments on the Pharo mailing list of all places quoting the post from the 11th before I even responded. I did not have a chance to respond to your nicely detailed post until late this morning[5] and never did see your post on this list until this afternoon, because it was titled "Pharo-users Digest, Vol 57, Issue 39". At the end of the day you seem to be upset that an out-of-the-box client/server solution does not exist for GemStone and my answer to that is that we have had out-of-the-box client/server solutions for over 2 decades; for VW and VAÂ and we have active customers who have been running applications using this technology for just as long ... We just do not have the same kind of solution for Pharo, but as I mentioned in my email from this morning[5] we are headed in that direction. However, with 2 decades of experience under our belts we will take a slightly different approach to the object replication architecture this time around - and the reality is that there are several possible directions to take.. It is also worth mentioning that we have Seaside customers using a develop in Pharo deploy in GemStone methodology who have been running production applications continuously for over a decade. I mentioned in my mail from this morning that I would be willing to work with on your proof of concept and that statement still stands. Using GemStone as an object store for visualizing and inspecting objects derived from big data streams does seem to be an application that GemStone is well suited for but there is work that needs to be done to make it a reality as there is no out-of-box solution for this problem at the moment. Dale [1] http://forum.world.st/tode-st-Gemstone-Seaside-tp5062364.html [2] http://forum.world.st/tode-st-Gemstone-Seaside-tp5062364p5062601.html [3] http://forum.world.st/tode-st-Gemstone-Seaside-tp5062364p5062370.html [4] http://forum.world.st/tode-st-Gemstone-Seaside-tp5062364p5062837.html [5] http://forum.world.st/tode-st-Gemstone-Seaside-tp5062364p5063206.html On 1/15/18 5:42 AM, Ian Ian wrote: > W.R.T Database Connectivity: > > Hi All, > > The database connectivity issue as discussed is near and dear to my > evaluation of Smalltalk(s).Â It is a huge problem/stumbling block as I > see it. > > Here Is a cut and paste of my replay to the Gemstone users group: > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Hi Dale, > > I am evaluating Gemstone as an application server/big data > repository.Â Hence my confusion up till now. > > I work for an organization that has rather large data storage > requirements (understatement:Â into the 100's of petabyte range). > > Currently, several independent Apache Hadoop stacks are used to manage > this data.Â There are several serious issues that are evident with > this setup, prime of which is object to relational mapping errors (as > datasets in a given space change over time - data is mandated to be > kept into perpetuity) regardless of whether the database is NoSQL, SQL > of any other schema.Â The issue bubbles up into the organization > application layers of many diverse and distributed verticals.Â > Maintenance of the system is not trivial and is very expensive and > time consuming. > > We use virtualization (in the VMWare sense) to create views into the > data.Â Generally, access is a split between virtualized kiosk systems, > another level of indirection, where by mandate, we must now archive > the state of the vm's as well as business data, and direct workstation > access,Â Â Not fun, error prone and hardware intensive (from a data > storage perspective). > > As I have been reading about object databases and what they are said > to buy in terms of efficiency (objects being stored natively and > directly) coupled with the fact the we are virtualizing everything we > can, I, along with a couple of colleagues, thought that we should take > a look at what new (laugh) technologies were available. > > After a little time I came across Gemstone.Â Did my reading and > research and after a period of semantic confusion (still going) became > enamored with the possibilities. > > All this said, from a network, sys admin point of view, an image that > contains the application and it's objects is a godsend if object > persistence was guaranteed.Â It would allow me to archive a self > contained living blob that manages its own living state (in the VMWare > snapshot sense) and at the same time the data is available to other > blobs/views (seaside). > > On views in to the data store: > > Currently data mining occurs on the application layer (rather than > database level views).Â Various development groups create views > (applications) to access (possibly update, if they are the owning > group) the data.Â As mandate trickle (waterfall) from above new data > points can be added or removed (some of the mandate for this is > governed by changing regulations - in other words it must be done > regardless of the technical difficulties involved).Â You can image the > difficulties and manpower involved. > > This brings me back to the application server. Currently, whatever > tool a group uses to access the data, be it browser, remote client > application, whatever have you (generally based on the skill sets in > the group), requires a set of policies and procedures wrapped around > the effort (mandated disaster recovery and etc...).Â Tones of work > that can never be standardized in any way but nevertheless must be > documented and managed. > > Okay (to long winded self): > > Having spent some time looking at this problem from a smalltalk, image > virtualization, integrated application management perspective, all my > issues could be alleviated within a single technology. Yippee! > > The spawning of an idea: > > Amber -> Seaside -> Gemstone.Â One language (integrated properly -> > one tool). > > Amber: > > *Â Each group, with a small learning curve could create and manage > their own views into the data. > *Â The serialized javascript, once the client was developed, could be > streamed from the application server (Seaside/Gemstone) on demand.Â It > just becomes another object. > > Seaside: > > * Client interface manager transport system (HTTP) for any and all views. > > Gemstone: > > * Object level persistence with no forced mappings of any kind. > * Extensibility. (can gemstone handle data levels in the petadata range?) > > Cool!: > > * Users/Developers of the system have a completely controlled view > into the image/system (perhaps a clustered NginX front end?). > * Image access at the machine level is completely controlled/secure. > * Everything in one place with system knowledge transfer and expertise > leveraged vertically and horizontally. > * The images can easily be archived in whatever manner (at the bit > level using any version control system if desired) at whatever schedule. > * Another level of 'complete system' security achieved. (Way cool!!) > * Whole systems is a single entity!Â Fantastical! > * A significantly smaller foot print. > > * Cost reductions, increased efficiency all the way through... > > Pipe dream?Â Maybe but I think it is doable over time with smalltalk.Â > The same system is not doable in any other way with any other > technology without extensive dollars and effort and once built making > dynamic unplanned for changes virtually impossible. You are locked in > (Silly but happens all the time). With the system I envision, changes, > even schema changes, are relatively easy. > > For my money: > > * Gemtalk should integrate development tools directly into Gemstone > (Gemstone with seaside is an order of magnitude more useful than > without it) > * Gemtools should be in the reference client - Pharo - permanently > (CGI/RPC, everything). > Â What does the tODE buy me, other than access, but a shell? > Â Give Pharo a permanent seamless object store - make it easy for > me/others. The user base will grow. > Â Gemtalk will sell more licenses in the long run. > * Gemstone should be re-branded as a fully functional pure OO > application server with extensible secure persistence built in. > (slight difference but HUGE!!! - MS, in truth, is a marketing company) > Â Let's see if java can compete with that! (Not - they would be forced > to make changes just to try.) > * There are more but I am saying too much as it is.... > > Lastly, > > My proof of concept: > > 1.Â Create a seaside app > 2.Â Create its client in amber. > 3.Â Upload the client js to the stone. > 4.Â Stream the client(s) to the browser based on some form of uri > 5.Â Manipulated the data store (gemstone) with the client. > 6.Â Cluster the system. > 7.Â Develop a DR process. > 8.Â Sell it > > Should on the face of it be simple? > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > I know what this means for me as an evaluator of Smalltalk as a viable > system.Â I only include my response to that group to simply to show my > pain. > > The responses I got were on the order of 'you could do this,' or write > that...Â Neither answer, from my perspective is valid. > > I reiterate that Pharo with built in persistence as in a fully > integrated Gemstone is, IMHO, the best approach to take.Â The fact > that gemstone as the only non-flattened oo extensible database is > sad.Â Â Worse is that Gemtalk sees Gemstone as a separate entity.Â > Object persistence requires application level integration ie. gemstone > requires you to develop your app and have it run in the stone in order > to persist.Â The Gemtalk philosophy is thus flawed on the face of it. > > I don't means to disparage anyone just stating facts as I see them. > > > > > > On 15 January 2018 at 08:22, <pharo-users-request(a)lists.pharo.org > <mailto:pharo-users-request@lists.pharo.org>> wrote: > > Send Pharo-users mailing list submissions to > pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org> > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org > <http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org> > or, via email, send a message with subject or body 'help' to > pharo-users-request(a)lists.pharo.org > <mailto:pharo-users-request@lists.pharo.org> > > You can reach the person managing the list at > pharo-users-owner(a)lists.pharo.org > <mailto:pharo-users-owner@lists.pharo.org> > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pharo-users digest..." > > Today's Topics: > > Â Â 1. Re: Databases (Sven Van Caekenberghe) > Â Â 2. Re: [Moose-dev] [ann] gt connector (Sven Van Caekenberghe) > Â Â 3. Re: [Moose-dev] [ann] gt connector (Kjell Godo) > Â Â 4. Re: [ANN] OpenSSL-Pharo works on Windows (Tudor Girba) > Â Â 5. Set Rounding mode for IEEE floating point operations > Â Â Â (Steffen M?rcker) > Â Â 6. [Seaside] WAComponent instances tree + proper page refreshing > Â Â Â for user (back button) - confusion (Petr Fischer) > > > ---------- Forwarded message ---------- > From:Â Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> > To:Â Benoit St-Jean <bstjean(a)yahoo.com <mailto:bstjean@yahoo.com>>, > Any question about pharo is welcome <pharo-users(a)lists.pharo.org > <mailto:pharo-users@lists.pharo.org>> > Cc: > Bcc: > Date:Â Mon, 15 Jan 2018 10:55:04 +0100 > Subject:Â Re: [Pharo-users] Databases > BenoÃ®t, > > Yes, of course databases are important and I know many users ask > for them, but on the other hand, the low development activity can > only mean that there is not enough interest (or some existing > solutions work well enough). > > There are many SQL and non-SQL databases out there, as well as > many, incompatible Smalltalk implementations. I do not believe > that there can be one magic solution to fix all problems everywhere. > > Remember that setting up a database is often a challenge by itself. > > I do not think the current situation is bad, it is just confusing. > Making a good meta overview (i.e. documentation writing) and > testing solutions would already help many people. > > To add to your list, I recently wrote a new PostgreSQL client, P3, > that is using only TCP networking (no native library mess). It > supports most recent Pharo distributions. > > https://github.com/svenvc/P3 > > P3 can be used under Glorp. Glorp in still being maintained and in > active use, but could use some love in the promotion department. > > Here is some documentation > > http://files.pharo.org/books-pdfs/booklet-Glorp/2017-05-02-Glorp-Spiral.pdf > <http://files.pharo.org/books-pdfs/booklet-Glorp/2017-05-02-Glorp-Spiral.pdf> > https://medium.com/concerning-pharo/reddit-st-in-10-cool-pharo-classes-1b53… > <https://medium.com/concerning-pharo/reddit-st-in-10-cool-pharo-classes-1b53…> > https://github.com/SquareBracketAssociates/Booklet-Reddit > <https://github.com/SquareBracketAssociates/Booklet-Reddit> > (updated version of the former) > https://bintray.com/squarebracketassociates/wip/download_file?file_path=red… > <https://bintray.com/squarebracketassociates/wip/download_file?file_path=red…> > > Actually, few languages have as nice an Object Relational Mapper > as Glorp. > > There is also Voyage that seems quite popular. > > Sven > > > On 15 Jan 2018, at 10:13, Benoit St-Jean via Pharo-users > <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> > wrote: > > > > > > From: Benoit St-Jean <bstjean(a)yahoo.com <mailto:bstjean@yahoo.com>> > > Subject: Databases > > Date: 15 January 2018 at 10:13:10 GMT+1 > > To: "pharo-users(a)lists.pharo.org > <mailto:pharo-users@lists.pharo.org>" <pharo-users(a)lists.pharo.org > <mailto:pharo-users@lists.pharo.org>>, > "squeak-dev(a)lists.squeakfoundation.org > <mailto:squeak-dev@lists.squeakfoundation.org>" > <squeak-dev(a)lists.squeakfoundation.org > <mailto:squeak-dev@lists.squeakfoundation.org>> > > Reply-To: Benoit St-Jean <bstjean(a)yahoo.com > <mailto:bstjean@yahoo.com>> > > > > > > Bear with me for a moment... > > > > First and foremost, this post is *not intended in any way* to > criticize the work of anyone who could have worked on those > packages/projects/frameworks. > > > > Now, I'll tell you a story to make my point. > > > > Often times, in public or in private, I help newcomers on Quora, > IRC, the mailing list(s) or elsewhere with various Smalltalk > environments.Â Often times, I try to be helpful getting them > started on Squeak or Pharo.Â Often times, they are just amazed by > how powerful Smalltalk is... > > > > Now, the sad part.Â Everything goes well until they just want to > "code something" to experiment and they ask me about databases... > > > > -How can I connect to a MySQL (or insert your favorite database > here) with Squeak/Pharo ? > > > > > > As far as I can remember, the database connectivity with > Squeak/Pharo has always been an area where, as a Squeak/Pharo > community, we suck big time.Â I don't recall the last time I > loaded a package, ran the tests and everything was fine.Â There is > almost ALWAYS something broken with the databases packages.Â > Understandibly, Squeak and Pharo were for a long time moving > targets.Â Whether it was VM changes (FFI, NativeBoost, uFFI, 32 vs > 64 bit, OS differences/problems, differences between Squeak and > Pharo, etc), code refactoring (cryptography class name changes), > the DateAndTime/Timestamp/TimeStamp/Date(Magnitude)/Date(Timespan) > were used from one version to the other in the driver, code that > was removed by some cleanup, compiler > changes/problems/incompatibilities, etc.Â In other words, database > connectivity needs some love. > > > > Unfortunately, it looks like there doesn't seem to be a > consensus or a shared desire to fix things *together*. There is > duplicate effort all over the place.Â Just as an example, I listed > the various implementations of MySQL packages that exists (I did > not list the 8-9 of them that had no code but a project listed on > one of those sites). So, let's say you are a newcomer and you want > to connect to a MySQL database.Â Here are the choices you are > offered (and remember, as a newcomer, you have NO clue which one > to pick) : > > > > > > Databases supported : Project name > > > > 1) SqueakSource > > > > MySQL : Automatic Object Storage To MySQL > > OpenDBX > > SqueakDBX > > > > > > 2) SmalltalkHub > > > > DBX/Talk / DBXDatabaseModel > > GlorpDriverMySQL > > PharoExtras / ODBC > > DBXTalk / Garage > > UDBC > > UDBC2 > > > > 3) GitHub.io > > > > dbxtalk > > > > 4) GitHub > > > > pharo-rdbms/garage > > > > Now, let's say you picked one package.Â In some cases, if you > are lucky, the code will load without any problem or warning.Â And > then, you run the tests.Â That is where it almost *always* breaks! > > > > Today, I tried to load *each and everyone of them* in a Pharo > 6.1 (Windows) image : none of them worked right out of the box! > > > > In other words, that newcomer I told you about just goes from > "WOW!!!" to "WHAT?!?!" in 10 seconds.Â People are usually not so > impressed with a TestRunner that fails a gazillion unit tests... > > > > So, now the nice part... > > > > Database connectivity is, in my humble opinion, a MUST for Pharo > and Squeak. I think it's about time we do *something* about the > current state of this mess.Â There are enough brilliant and > talented people in the Squeak and Pharo communities to fix this > situation.Â At least, we could start *talking* about it if we want > to address the problems. Ideally, we would come up with a will to > change things and establish a plan. > > > > In a perfect world, we'd have something like JDBC (or some kind > of Smalltalk universal driver) in Smalltalk for native drivers.Â > Plus ODBC connectivity. Plus it would have to work > right-out-of-the-box.Â Plus documentation that has at least an > example with Connect/SELECT/UPDATE/DELETE/CREATE/DROP/disconnect > simple examples to get newbies started.Â Plus a solid suite of > tests to beat the sh*t out of that code. Plus a compatibility > layer for Squeak/Pharo differences.Â To that regard, Glorp is an > example to follow!Â IMHO, it's about time we share stuff to > maximize our efforts! > > > > As I told someone recently, it's about time we do something > about databases (RDBMS).Â And as I told that person, I don't mind > writing Smalltalk code and SQL scripts and running tests.Â Even do > performance testing.Â My MySQL Server currently has close to 1 > billion records to torture the MySQL driver if needed.Â And I can > also work on SQLite. And Oracle.Â And DB/2.Â And MySQL Server.Â > And I don't mind installing other RDBMS on my machine and test > other driver ports.Â Now, it's just a matter of knowing if we all > want to work together. > > > > As for OpenDBX/DBX, I'm not sure.Â Having another dependency > (and C code) that we more or less control doesn't inspire me.Â I > have yet to see how DBX/OpenDBX gives me any advantage over, say, > ODBC... > > > > As I said, it's time to discuss! > > > > Anyone interested? > > > > ----------------- > > BenoÃ®t St-Jean > > Yahoo! Messenger: bstjean > > Twitter: @BenLeChialeux > > Pinterest: benoitstjean > > Instagram: Chef_Benito > > IRC: lamneth > > Blogue: endormitoire.wordpress.com > <http://endormitoire.wordpress.com> > > "A standpoint is an intellectual horizon of radius zero".Â (A. > Einstein) > > > > > > > > > > ---------- Forwarded message ---------- > From:Â Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> > To:Â Moose-related development <moose-dev(a)list.inf.unibe.ch > <mailto:moose-dev@list.inf.unibe.ch>> > Cc:Â Pharo Development List <pharo-dev(a)lists.pharo.org > <mailto:pharo-dev@lists.pharo.org>>, Any question about pharo is > welcome <pharo-users(a)lists.pharo.org > <mailto:pharo-users@lists.pharo.org>> > Bcc: > Date:Â Mon, 15 Jan 2018 11:19:59 +0100 > Subject:Â Re: [Pharo-users] [Moose-dev] [ann] gt connector > > > > On 14 Jan 2018, at 22:54, Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>> wrote: > > > > Hi, > > > > Towards the end of last year we worked on GT Connector, a new > kind of interface that allows us to exercise and test the limits > (or the lack thereof) of Bloc. > > > > It looks like this: > > <connector2.jpeg> > > > > You can see it in action here: > > https://twitter.com/feenkcom/status/936109463462965248 > <https://twitter.com/feenkcom/status/936109463462965248> > > Incredible stuff ! > > Keep on pushing the boundaries. > > > In the current implementation, the Connector allows us to > navigate and connect example methods. The focus is not on > examples, but on the connections. We used examples because the > engine was already around and offered us a nice use case. We want > to extend it in the near future to other kinds of objects. > > > > There are a couple of things that are worth noting: > > â¢ The editor works live, and the connection points appear and > disappear as you type. > > â¢ The layout of the editor elements is based on a tree-based > graph layout that only works with constrains (no actual visible > edges between the editor elements). > > â¢ The editor works live, so adding new elements to the scene > properly rearranges the scene. > > â¢ But, perhaps, the most exciting part is the fact that the > lines connect an element from inside the text editor element with > another that lives outside of the editor element. > > > > All these validate the architecture of Bloc of having exactly > one rendering tree. It was not an obvious goal a couple of years > ago, but we are really happy that it works. > > > > To put it in perspective, let's compare this with the html > world. Text is text is rendered through the DOM tree. If you want > graphics you might use something like SVG which comes with its own > tree. However, these are two distinct worlds, and you cannot go > from one to another, or at least not easily. This is the case in > most engines we looked at. > > > > Why is this important? One thing we learn in the Smalltalk world > is that covering the same space with less concepts opens up a > whole dimension of creativity that is simply not possible outside > of it. > > > > The goal with Bloc is to enable new kinds of user interfaces. As > we are late to the game of modern interfaces, even though the > field was invented in Smalltalk, our only chance to take the lead > again is to rethink the model. > > > > Let's look at the Connector again. In most user interfaces we > have panes on the outside, and visuals confined within the > boundaries of those panes. Interestingly, we can trace this > pattern to the very first Smalltalk interfaces. In the Connector > interface we have no boundaries with text and visualization being > intertwined to form a new kind of workflow. > > > > Talking about workflows, we now have two distinct and novel ways > to explore examples: one is Connector, and the other one is the > expandable code editor. For example, the scene from above looks > like this in the example expanding editor: > > > >Â <editor.jpg> > > > > > > Both of these interfaces are not found in other infrastructures, > and yet they were both inexpensive to implement in Bloc. > > > > We believe this will have a deep impact for all sorts of > interfaces, and especially for the IDE. If you are interested in > more details related to the IDE, take a look at the following > paper from 2015: > > > http://scg.unibe.ch/archive/papers/Girb15b-PervasiveSoftwareVisualizations.… > <http://scg.unibe.ch/archive/papers/Girb15b-PervasiveSoftwareVisualizations.…> > > > > Please let us know what you think. > > > > Cheers, > > The feenk team > > > > > > -- > > www.tudorgirba.com <http://www.tudorgirba.com> > > www.feenk.com <http://www.feenk.com> > > > > "What is more important: To be happy, or to make happy?" > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch> > > https://www.list.inf.unibe.ch/listinfo/moose-dev > <https://www.list.inf.unibe.ch/listinfo/moose-dev> > > > > > > ---------- Forwarded message ---------- > From:Â Kjell Godo <squeaklist(a)gmail.com <mailto:squeaklist@gmail.com>> > To:Â Moose-related development <moose-dev(a)list.inf.unibe.ch > <mailto:moose-dev@list.inf.unibe.ch>> > Cc:Â Any question about pharo is welcome > <pharo-users(a)lists.pharo.org > <mailto:pharo-users@lists.pharo.org>>, Pharo Development List > <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> > Bcc: > Date:Â Mon, 15 Jan 2018 10:44:26 +0000 > Subject:Â Re: [Pharo-users] [Moose-dev] [ann] gt connector > i want to use it > > > ---------- Forwarded message ---------- > From:Â Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> > To:Â Any question about pharo is welcome > <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> > Cc: > Bcc: > Date:Â Mon, 15 Jan 2018 12:20:00 +0100 > Subject:Â Re: [Pharo-users] [ANN] OpenSSL-Pharo works on Windows > Thanks a lot! > > Doru > > > > On Dec 20, 2017, at 8:55 AM, Pierce Ng <pierce(a)samadhiweb.com > <mailto:pierce@samadhiweb.com>> wrote: > > > > Hi all, > > > > OpenSSL-Pharo now works on Windows. Tested on Windows 10 with a > fresh 32-bit > > Pharo 6.1 zip package downloaded from pharo.org > <http://pharo.org>. On Windows this library uses > > libeay.dll which is bundled with the Pharo VM. > > > >Â Metacello new > >Â Â baseline: 'OpenSSL'; > >Â Â smalltalkhubUser: 'PierceNg' project: 'OpenSSL-Pharo'; > >Â Â load. > > > > Pierce > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > www.feenk.com <http://www.feenk.com> > > "No matter how many recipes we know, we still value a chef." > > > > > > > > > > > > ---------- Forwarded message ---------- > From:Â "Steffen MÃ¤rcker" <merkste(a)web.de <mailto:merkste@web.de>> > To:Â Any question about pharo is welcome > <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> > Cc: > Bcc: > Date:Â Mon, 15 Jan 2018 12:27:06 +0100 > Subject:Â [Pharo-users] Set Rounding mode for IEEE floating point > operations > Hi, > > is there any way to set the rounding mode for IEEE floating point > operations? Maybe something like > > Double roundToMinusInfWhile: [... code goes here ...]Double > roundToZeroWhile: [... more code here ...] > > > If not, is it possible to add this behavior, e.g., via a custom > primitive? > > Best, Steffen > > > > > ---------- Forwarded message ---------- > From:Â Petr Fischer <petr.fischer(a)me.com <mailto:petr.fischer@me.com>> > To: pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org> > Cc: > Bcc: > Date:Â Mon, 15 Jan 2018 14:21:28 +0100 > Subject:Â [Pharo-users] [Seaside] WAComponent instances tree + > proper page refreshing for user (back button) - confusion > Hello, sorry for crossposting (from Seaside list), but I probably > do not understand something very basic in Seaside - how to > properly refresh instantiated WAComponent tree (data views) and > when (+ back button problems). > > Seaside manual says ("About Callbacks" section): > > "Do not change state while rendering... Just produce output and > define callbacks that do the fancy stuff you canât do while > rendering." > > OK, then my small example: > > 1) Suppose I have a page - WAMyListPage (WAComponent sub class), > which presents a list of items from DB table, easy. > > 2) When WAMyListPage is instantiated at the beginnig, it loads 10 > rows from the DB, creates WAMyItem (WAComponent subclass) for > every DB row and puts these WAMyItem instances to the WAMyListPage > instance variable "items" (OrderedCollection) > > 3) WAMyListPage is rendered to the browser (simple render call on > all WAMyItem "items" components in a loop) - 10 items (db rows) > are displayed - OK > > 4) User 1 clicks on the WAMyItem component from the rendered list > (on the WAMyListPage) and goes into item detail page (detail page > is not interesting here) > > 5) User 2 deletes 5 items/rows from the database (some way) > > 6) User 1 clicks browser back button and returns to the > WAMyListPage, two cases can occur: > > Â Â Â Â Â Â Â Â A) typically, the "list page" is cached in the > browser and browser immediatelly renders the list page from the > cache (without request) - with all 10 old items (no refresh, > broken old view with some non existing items) > > Â Â Â Â Â Â Â Â B) request from the browser to the Seaside app is > made again (with old Seaside URL from browser history), then > Seaside app just renders old state of WAMyListPage instance from > the history and again - there is all 10 old WAMyItem items > instantiated, so, broken again, old items in the view > > My question - where can I do a proper refresh of WAMyListPage list > items? (manual refresh button in the Seaside app is unacceptable) > > Note: I can solve this by reloading WAMyListPage "items" instvar > collection in every renderContentOn: (reload from DB, reload all > WAMyItem instances) + instruct the browser to not cache any web > page (in HTTP headers), so in point (6A) above, browser will > ignore caching and make request to Seaside app again. > In this way, everything works, WAMyListPage is actual every time, > but main Seaside rule "Do not change state while rendering" is > violated (WAMyItems are reinstantiated in every renderContentOn:). > > So, how do I face this? Thanks very much! pf > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.pharo.org <mailto:Pharo-users@lists.pharo.org> > http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org > <http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org> > >

Jan. 16, 2018

ZnClient POST then GET of different URL path, GET has POST's entity

by PAUL DEBRUICKER

Hi - Should #resetEntity be called automatically for long lived sessions ? I see that it is called automatically for HEAD and DELETE methods. If you do a |client | client:=ZnClient new. client get: 'http://example.com/getPath' client inspect client post: 'http://example.com' contents:'My Contents' client inspect. client get: 'http://example.com/getPath' client inspect. client close. and then look at the changed headers between the first and last GET you can see that the body from the POST was sent in the 2nd GET request. I can't think of a time when you'd want that, generally. Maybe it would be better to make keeping the entity around as the exception in all cases and ask for it specifically when you want it. I'm not sure of the answer I was just surprised by the behavior and can definitely send #resetEntity for my use case. Paul

Jan. 16, 2018

Re: [Pharo-users] Databases

by Offray Vladimir Luna CÃ¡rdenas

Hi, In my casoe UDBC2 and SQLite have worked pretty well, but I have a problem in the transition from Pharo 4.0 to 5.0 and UDBC that was quickly fixed once I asked for community support (if I remember was related with the location of the Sqlite binary). I could help with testing such scenario. But yes, SQLite is kind of the out of the box solution for databases in all other programming languages, so we need to be sure this experience is working for our users also (I remember one of our workshop participants complaining about how this default was even alien for Pharo). It's difficult to transmit some sense of stability in a quickly evolving software like this, but I think that is important to have some defaults working out of the box. Cheers, Offray On 15/01/18 04:13, Benoit St-Jean via Pharo-users wrote: > Subject: > Databases > From: > Benoit St-Jean <bstjean(a)yahoo.com> > Date: > 15/01/18 04:13 > > To: > "pharo-users(a)lists.pharo.org" <pharo-users(a)lists.pharo.org>, > "squeak-dev(a)lists.squeakfoundation.org" > <squeak-dev(a)lists.squeakfoundation.org> > > > Bear with me for a moment... > > First and foremost, this post is *not intended in any way* to > criticize the work of anyone who could have worked on those > packages/projects/frameworks. > > Now, I'll tell you a story to make my point. > > Often times, in public or in private, I help newcomers on Quora, IRC, > the mailing list(s) or elsewhere with various Smalltalk environments.Â > Often times, I try to be helpful getting them started on Squeak or > Pharo.Â Often times, they are just amazed by how powerful Smalltalk > is...Â > > Now, the sad part.Â Everything goes well until they just want to "code > something" to experiment and they ask me about databases... > > -How can I connect to a MySQL (or insert your favorite database here) > with Squeak/Pharo ? > > > As far as I can remember, the database connectivity with Squeak/Pharo > has always been an area where, as a Squeak/Pharo community, we suck > big time.Â I don't recall the last time I loaded a package, ran the > tests and everything was fine.Â There is almost ALWAYS something > broken with the databases packages.Â Understandibly, Squeak and Pharo > were for a long time moving targets.Â Whether it was VM changes (FFI, > NativeBoost, uFFI, 32 vs 64 bit, OS differences/problems, differences > between Squeak and Pharo, etc), code refactoring (cryptography class > name changes), the > DateAndTime/Timestamp/TimeStamp/Date(Magnitude)/Date(Timespan) were > used from one version to the other in the driver, code that was > removed by some cleanup, compiler changes/problems/incompatibilities, > etc.Â In other words, database connectivity needs some love. > > Unfortunately, it looks like there doesn't seem to be a consensus or a > shared desire to fix things *together*.Â There is duplicate effort all > over the place.Â Just as an example, I listed the various > implementations of MySQL packages that exists (I did not list the 8-9 > of them that had no code but a project listed on one of those sites).Â > So, let's say you are a newcomer and you want to connect to a MySQL > database.Â Here are the choices you are offered (and remember, as a > newcomer, you have NO clue which one to pick) : > > > Databases supported : Project name > > 1) SqueakSource > > MySQL : Automatic Object Storage To MySQL > OpenDBX > SqueakDBX > > > 2) SmalltalkHub > > DBX/Talk / DBXDatabaseModel > GlorpDriverMySQL > PharoExtras / ODBC > DBXTalk / Garage > UDBC > UDBC2 > > 3) GitHub.io > > dbxtalk > > 4) GitHub > > pharo-rdbms/garage > > Now, let's say you picked one package.Â In some cases, if you are > lucky, the code will load without any problem or warning.Â And then, > you run the tests.Â That is where it almost *always* breaks! > > Today, I tried to load *each and everyone of them* in a Pharo 6.1 > (Windows) image : none of them worked right out of the box! > > In other words, that newcomer I told you about just goes from "WOW!!!" > to "WHAT?!?!" in 10 seconds.Â People are usually not so impressed with > a TestRunner that fails a gazillion unit tests... > > So, now the nice part... > > Database connectivity is, in my humble opinion, a MUST for Pharo and > Squeak. I think it's about time we do *something* about the current > state of this mess.Â There are enough brilliant and talented people in > the Squeak and Pharo communities to fix this situation.Â At least, we > could start *talking* about it if we want to address the problems.Â > Ideally, we would come up with a will to change things and establish a > plan. > > In a perfect world, we'd have something like JDBC (or some kind of > Smalltalk universal driver) in Smalltalk for native drivers.Â Plus > ODBC connectivity. Plus it would have to work right-out-of-the-box.Â > Plus documentation that has at least an example with > Connect/SELECT/UPDATE/DELETE/CREATE/DROP/disconnect simple examples to > get newbies started.Â Plus a solid suite of tests to beat the sh*t out > of that code. Plus a compatibility layer for Squeak/Pharo > differences.Â To that regard, Glorp is an example to follow!Â IMHO, > it's about time we share stuff to maximize our efforts! > > As I told someone recently, it's about time we do something about > databases (RDBMS).Â And as I told that person, I don't mind writing > Smalltalk code and SQL scripts and running tests.Â Even do performance > testing.Â My MySQL Server currently has close to 1 billion records to > torture the MySQL driver if needed.Â And I can also work on SQLite.Â > And Oracle.Â And DB/2.Â And MySQL Server.Â And I don't mind installing > other RDBMS on my machine and test other driver ports.Â Now, it's just > a matter of knowing if we all want to work together. > > As for OpenDBX/DBX, I'm not sure.Â Having another dependency (and C > code) that we more or less control doesn't inspire me.Â I have yet to > see how DBX/OpenDBX gives me any advantage over, say, ODBC... > > As I said, it's time to discuss! > > Anyone interested? > Â > -----------------

Jan. 16, 2018

Re: [Pharo-users] [ann] gt connector

by Offray Vladimir Luna CÃ¡rdenas

Seems really interesting. I think there is a lot of possibility in such new interfaces powered by GT Tools, but exploring them is a lonely path. mostly if you want to create end user tools. Cheers, Offray On 14/01/18 16:54, Tudor Girba wrote: > Hi, > Â > Towards the end ofÂ last year we worked on GT Connector, a new kind of > interface that allows us toÂ exercise and test the limits (or the lack > thereof) ofÂ Bloc. > Â > It looks like this: > > Â > You can see it inÂ action here: > https://twitter.com/feenkcom/status/936109463462965248 > Â > In the currentÂ implementation, the Connector allows us to navigate and > connect example methods. The focus isÂ not on examples, but on the > connections. We usedÂ examples because the engineÂ was already around > and offered us a nice use case. We want to extend it in theÂ near > future to other kinds of objects. > > There are a coupleÂ of things that are worth noting: > â¢ The editor works live, andÂ the connection points appear and > disappear as you type. > â¢ The layout of the editorÂ elements is based on a tree-based graph > layout that only works withÂ constrains (no actual visible edges > betweenÂ the editor elements). > â¢ The editor works live, soÂ adding new elements to the scene properly > rearranges the scene. > â¢ But, perhaps, the mostÂ exciting part is the fact that the lines > connect an element from insideÂ the text editor element with another > thatÂ lives outside of the editorÂ element. > Â > All these validateÂ the architecture of Bloc of having exactly one > rendering tree. It was not anÂ obvious goal a couple of years ago, but > we are reallyÂ happy that it works. > Â > To put it inÂ perspective, let's compare this with the html world. Text > is text is renderedÂ through the DOM tree. If you want graphics you > might useÂ something like SVGÂ which comes with its own tree. However, > these are two distinct worlds, and youÂ cannot go from one to another, > or at least notÂ easily. This is the case in mostÂ engines we looked at. > Â > Why is thisÂ important? One thing we learn in the Smalltalk world is > that covering the sameÂ space with less concepts opens up a whole > dimension ofÂ creativity that isÂ simply not possible outside of it. > Â > The goal with BlocÂ is to enable new kinds of user interfaces. As we > are late to the game of modernÂ interfaces, even though the field was > invented inÂ Smalltalk, our only chance toÂ take the lead again is to > rethink the model. > Â > Let's look at theÂ Connector again. In most user interfaces we have > panes on the outside, andÂ visuals confined within the boundaries of > those panes.Â Interestingly, we canÂ trace this pattern to the very > first Smalltalk interfaces. In the ConnectorÂ interface we have no > boundaries with text andÂ visualization being intertwinedÂ to form a new > kind of workflow. > Â > Talking aboutÂ workflows, we now have two distinct and novel ways to > explore examples: one isÂ Connector, and the other one is the > expandable codeÂ editor. For example, the scene from above looks like > this in the example expanding editor: > > Â > > > Both of these interfaces areÂ not found in other infrastructures, and > yet they were both inexpensive toÂ implement in Bloc. > > We believe this willÂ have a deep impact for all sorts of interfaces, > and especially for the IDE. IfÂ you are interested in more details > related to the IDE,Â take a look at theÂ following paper from 2015: > http://scg.unibe.ch/archive/papers/Girb15b-PervasiveSoftwareVisualizations.… > Â > Please let us knowÂ what you think. > Â > Cheers, > The feenk team > > > -- > www.tudorgirba.com > www.feenk.com > > "What is more important: To be happy, or to make happy?" >

Jan. 16, 2018

Re: [Pharo-users] How to declare a do:[] loop for a matrix to read and acces its elements?

by Ben Coman

On 16 January 2018 at 05:47, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2018-01-15 18:04 GMT+01:00 Photon <nico-braun(a)live.de>: >> >> when I call the countNeighbours method i get an error: the block wants two >> arguments but I pass only one. >> This is probally because i want to pass x y but only really pass x wich >> ends >> up being a cell and not the index. >> >> I still have trouble thinking it trough. The indicieDo: method seems to >> make >> the matrix bigger?! I don`t quite understand it. > > > It should not, and looking at the implementation, it just iterates with two > loops 1 to number of rows times 1 to number of columns and calls your > block argument with the pair of indexes. > >> >> >> There must be an easy way to to figure out if the suroundings are alive or >> not. I mean its all there what I need and in my mind its so easy to >> discribe >> it with normal words. But to tell the machine witth syntax is another >> thing >> really :/ > > > About the surroundings, there is a nice method in Point > Point>>eightNeighbors, that gives you the coordinates of the eight > surrounding fields > for example: > (5@7) eightNeighbors "{(6@7). (6@8). (5@8). (4@8). (4@7). (4@6). (5@6). > (6@6)}" @all, side-question... I remember from Squeak Lasergame tutorial that it represented a grid as a Dictionary rather than an Array of Arrays. http://squeak.preeminent.org/tut2007/html/032.html #initializeCells Anyone have an opinion of the suitability of that approach in relation to grid sizing? cheers -ben > > with this method and if you iterate through all pairs of indices of the > matrix, you can > do your computation for every point, but you have to take care about the > points that don't > have valid matrix indices for some of their neighbours (like 0@0, the left > and top neighbours > may actually "on the other side of the matrix"). But you can take a look at > SequenceableCollection>>atWrap: how it deals with "wrapping around". > > > >> >> >> what if i selected only one element with do:[] and let its tell me its >> idices. I store them in a temp object and then I check outside the block >> the >> neighbours and add to the counter. Once this is done I repeat as many >> times >> as their elements in the matrix? >> >> Greetings

Jan. 15, 2018

Re: [Pharo-users] Pharo-users Digest, Vol 57, Issue 39

by Richard Sargent

"Worse is that Gemtalk sees Gemstone as a separate entity. Object persistence requires application level integration ie. gemstone requires you to develop your app and have it run in the stone in order to persist. The Gemtalk philosophy is thus flawed on the face of it." I would like to offer some correction and clarification here. First, the GemStone/S product does not provide a graphical user interface, so some of our customers do utilize other Smalltalk products for that capability. GemTalk Systems offers a product called GBS (GemBuilder for Smalltalk) which integrates into both VA Smalltalk and VisualWorks to provide seamless and efficient object replication between GemStone and client Smalltalks. (There are also GemBuilder for Java and GemBuilder for C. The latter facilitates FFI interfacing with the GemStone server from any programming language.) Quite a few GemStone customers use a "develop in Pharo and run in GemStone" philosophy for sophisticated web applications. The reasons for this are numerous, but do include performance. Marshalling, transferring, and unmarshalling, possibly in two directions, is an overhead. There is always the usual client/server performance balancing when running an application split across tiers in that way. Last, I am assuming the binding in "gemstone requires you to develop your app and have it run in the stone" is intended as "(gemstone requires you to develop your app and have it run) in the stone". As explained above, we do support a number of options for developing your application. ("in the stone" is an incorrect phrasing.) We do require you to run at least some part of your application in GemStone Smalltalk. That "some part" can range from as little as accessing and marshalling data right through running the entire application. The GemStone Smalltalk VM can run on the same server as the Stone (the repository manager) or on different servers with local page caches and intermediary page caches when running a large enough and complex enough application. Ian Ian wrote > W.R.T Database Connectivity: > > Hi All, > > The database connectivity issue as discussed is near and dear to my > evaluation of Smalltalk(s). It is a huge problem/stumbling block as I see > it. > > Here Is a cut and paste of my replay to the Gemstone users group: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Hi Dale, > > I am evaluating Gemstone as an application server/big data repository. > Hence my confusion up till now. > > I work for an organization that has rather large data storage requirements > (understatement: into the 100's of petabyte range). > > Currently, several independent Apache Hadoop stacks are used to manage > this > data. There are several serious issues that are evident with this setup, > prime of which is object to relational mapping errors (as datasets in a > given space change over time - data is mandated to be kept into > perpetuity) > regardless of whether the database is NoSQL, SQL of any other schema. The > issue bubbles up into the organization application layers of many diverse > and distributed verticals. Maintenance of the system is not trivial and > is > very expensive and time consuming. > > We use virtualization (in the VMWare sense) to create views into the data. > Generally, access is a split between virtualized kiosk systems, another > level of indirection, where by mandate, we must now archive the state of > the vm's as well as business data, and direct workstation access, Not > fun, error prone and hardware intensive (from a data storage perspective). > > As I have been reading about object databases and what they are said to > buy > in terms of efficiency (objects being stored natively and directly) > coupled > with the fact the we are virtualizing everything we can, I, along with a > couple of colleagues, thought that we should take a look at what new > (laugh) technologies were available. > > After a little time I came across Gemstone. Did my reading and research > and after a period of semantic confusion (still going) became enamored > with > the possibilities. > > All this said, from a network, sys admin point of view, an image that > contains the application and it's objects is a godsend if object > persistence was guaranteed. It would allow me to archive a self contained > living blob that manages its own living state (in the VMWare snapshot > sense) and at the same time the data is available to other blobs/views > (seaside). > > On views in to the data store: > > Currently data mining occurs on the application layer (rather than > database > level views). Various development groups create views (applications) to > access (possibly update, if they are the owning group) the data. As > mandate trickle (waterfall) from above new data points can be added or > removed (some of the mandate for this is governed by changing regulations > - > in other words it must be done regardless of the technical difficulties > involved). You can image the difficulties and manpower involved. > > This brings me back to the application server. Currently, whatever tool a > group uses to access the data, be it browser, remote client application, > whatever have you (generally based on the skill sets in the group), > requires a set of policies and procedures wrapped around the effort > (mandated disaster recovery and etc...). Tones of work that can never be > standardized in any way but nevertheless must be documented and managed. > > Okay (to long winded self): > > Having spent some time looking at this problem from a smalltalk, image > virtualization, integrated application management perspective, all my > issues could be alleviated within a single technology. Yippee! > > The spawning of an idea: > > Amber -> Seaside -> Gemstone. One language (integrated properly -> one > tool). > > Amber: > > * Each group, with a small learning curve could create and manage their > own views into the data. > * The serialized javascript, once the client was developed, could be > streamed from the application server (Seaside/Gemstone) on demand. It > just > becomes another object. > > Seaside: > > * Client interface manager transport system (HTTP) for any and all views. > > Gemstone: > > * Object level persistence with no forced mappings of any kind. > * Extensibility. (can gemstone handle data levels in the petadata range?) > > Cool!: > > * Users/Developers of the system have a completely controlled view into > the > image/system (perhaps a clustered NginX front end?). > * Image access at the machine level is completely controlled/secure. > * Everything in one place with system knowledge transfer and expertise > leveraged vertically and horizontally. > * The images can easily be archived in whatever manner (at the bit level > using any version control system if desired) at whatever schedule. > * Another level of 'complete system' security achieved. (Way cool!!) > * Whole systems is a single entity! Fantastical! > * A significantly smaller foot print. > > * Cost reductions, increased efficiency all the way through... > > Pipe dream? Maybe but I think it is doable over time with smalltalk. The > same system is not doable in any other way with any other technology > without extensive dollars and effort and once built making dynamic > unplanned for changes virtually impossible. You are locked in (Silly but > happens all the time). With the system I envision, changes, even schema > changes, are relatively easy. > > For my money: > > * Gemtalk should integrate development tools directly into Gemstone > (Gemstone with seaside is an order of magnitude more useful than without > it) > * Gemtools should be in the reference client - Pharo - permanently > (CGI/RPC, everything). > What does the tODE buy me, other than access, but a shell? > Give Pharo a permanent seamless object store - make it easy for > me/others. The user base will grow. > Gemtalk will sell more licenses in the long run. > * Gemstone should be re-branded as a fully functional pure OO application > server with extensible secure persistence built in. (slight difference but > HUGE!!! - MS, in truth, is a marketing company) > Let's see if java can compete with that! (Not - they would be forced to > make changes just to try.) > * There are more but I am saying too much as it is.... > > Lastly, > > My proof of concept: > > 1. Create a seaside app > 2. Create its client in amber. > 3. Upload the client js to the stone. > 4. Stream the client(s) to the browser based on some form of uri > 5. Manipulated the data store (gemstone) with the client. > 6. Cluster the system. > 7. Develop a DR process. > 8. Sell it > > Should on the face of it be simple? > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > I know what this means for me as an evaluator of Smalltalk as a viable > system. I only include my response to that group to simply to show my > pain. > > The responses I got were on the order of 'you could do this,' or write > that... Neither answer, from my perspective is valid. > > I reiterate that Pharo with built in persistence as in a fully integrated > Gemstone is, IMHO, the best approach to take. The fact that gemstone as > the only non-flattened oo extensible database is sad. Worse is that > Gemtalk sees Gemstone as a separate entity. Object persistence requires > application level integration ie. gemstone requires you to develop your > app > and have it run in the stone in order to persist. The Gemtalk philosophy > is thus flawed on the face of it. > > I don't means to disparage anyone just stating facts as I see them. > > > > > > On 15 January 2018 at 08:22, < > pharo-users-request@.pharo > > wrote: > >> Send Pharo-users mailing list submissions to >> > pharo-users@.pharo >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.pharo.org/mailman/listinfo/pharo-users_ >> lists.pharo.org >> or, via email, send a message with subject or body 'help' to >> > pharo-users-request@.pharo >> >> You can reach the person managing the list at >> > pharo-users-owner@.pharo >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Pharo-users digest..." >> >> Today's Topics: >> >> 1. Re: Databases (Sven Van Caekenberghe) >> 2. Re: [Moose-dev] [ann] gt connector (Sven Van Caekenberghe) >> 3. Re: [Moose-dev] [ann] gt connector (Kjell Godo) >> 4. Re: [ANN] OpenSSL-Pharo works on Windows (Tudor Girba) >> 5. Set Rounding mode for IEEE floating point operations >> (Steffen M?rcker) >> 6. [Seaside] WAComponent instances tree + proper page refreshing >> for user (back button) - confusion (Petr Fischer) >> >> >> ---------- Forwarded message ---------- >> From: Sven Van Caekenberghe < > sven@ > > >> To: Benoit St-Jean < > bstjean@ > >, Any question about pharo is >> welcome < > pharo-users@.pharo > > >> Cc: >> Bcc: >> Date: Mon, 15 Jan 2018 10:55:04 +0100 >> Subject: Re: [Pharo-users] Databases >> BenoÃ®t, >> >> Yes, of course databases are important and I know many users ask for >> them, >> but on the other hand, the low development activity can only mean that >> there is not enough interest (or some existing solutions work well >> enough). >> >> There are many SQL and non-SQL databases out there, as well as many, >> incompatible Smalltalk implementations. I do not believe that there can >> be >> one magic solution to fix all problems everywhere. >> >> Remember that setting up a database is often a challenge by itself. >> >> I do not think the current situation is bad, it is just confusing. Making >> a good meta overview (i.e. documentation writing) and testing solutions >> would already help many people. >> >> To add to your list, I recently wrote a new PostgreSQL client, P3, that >> is >> using only TCP networking (no native library mess). It supports most >> recent >> Pharo distributions. >> >> https://github.com/svenvc/P3 >> >> P3 can be used under Glorp. Glorp in still being maintained and in active >> use, but could use some love in the promotion department. >> >> Here is some documentation >> >> http://files.pharo.org/books-pdfs/booklet-Glorp/2017-05-02- >> Glorp-Spiral.pdf >> https://medium.com/concerning-pharo/reddit-st-in-10-cool- >> pharo-classes-1b5327ca0740 >> https://github.com/SquareBracketAssociates/Booklet-Reddit (updated >> version of the former) >> https://bintray.com/squarebracketassociates/wip/download_file?file_path= >> reddit-wip.pdf >> >> Actually, few languages have as nice an Object Relational Mapper as >> Glorp. >> >> There is also Voyage that seems quite popular. >> >> Sven >> >> > On 15 Jan 2018, at 10:13, Benoit St-Jean via Pharo-users < >> > pharo-users@.pharo >> wrote: >> > >> > >> > From: Benoit St-Jean < > bstjean@ > > >> > Subject: Databases >> > Date: 15 January 2018 at 10:13:10 GMT+1 >> > To: " > pharo-users@.pharo > " < > pharo-users@.pharo > >, " >> > squeak-dev@.squeakfoundation > " <squeak-dev@lists. > > squeakfoundation.org> >> > Reply-To: Benoit St-Jean < > bstjean@ > > >> > >> > >> > Bear with me for a moment... >> > >> > First and foremost, this post is *not intended in any way* to criticize >> the work of anyone who could have worked on those >> packages/projects/frameworks. >> > >> > Now, I'll tell you a story to make my point. >> > >> > Often times, in public or in private, I help newcomers on Quora, IRC, >> the mailing list(s) or elsewhere with various Smalltalk environments. >> Often times, I try to be helpful getting them started on Squeak or Pharo. >> Often times, they are just amazed by how powerful Smalltalk is... >> > >> > Now, the sad part. Everything goes well until they just want to "code >> something" to experiment and they ask me about databases... >> > >> > -How can I connect to a MySQL (or insert your favorite database here) >> with Squeak/Pharo ? >> > >> > >> > As far as I can remember, the database connectivity with Squeak/Pharo >> has always been an area where, as a Squeak/Pharo community, we suck big >> time. I don't recall the last time I loaded a package, ran the tests and >> everything was fine. There is almost ALWAYS something broken with the >> databases packages. Understandibly, Squeak and Pharo were for a long >> time >> moving targets. Whether it was VM changes (FFI, NativeBoost, uFFI, 32 vs >> 64 bit, OS differences/problems, differences between Squeak and Pharo, >> etc), code refactoring (cryptography class name changes), the >> DateAndTime/Timestamp/TimeStamp/Date(Magnitude)/Date(Timespan) were used >> from one version to the other in the driver, code that was removed by >> some >> cleanup, compiler changes/problems/incompatibilities, etc. In other >> words, database connectivity needs some love. >> > >> > Unfortunately, it looks like there doesn't seem to be a consensus or a >> shared desire to fix things *together*. There is duplicate effort all >> over >> the place. Just as an example, I listed the various implementations of >> MySQL packages that exists (I did not list the 8-9 of them that had no >> code >> but a project listed on one of those sites). So, let's say you are a >> newcomer and you want to connect to a MySQL database. Here are the >> choices >> you are offered (and remember, as a newcomer, you have NO clue which one >> to >> pick) : >> > >> > >> > Databases supported : Project name >> > >> > 1) SqueakSource >> > >> > MySQL : Automatic Object Storage To MySQL >> > OpenDBX >> > SqueakDBX >> > >> > >> > 2) SmalltalkHub >> > >> > DBX/Talk / DBXDatabaseModel >> > GlorpDriverMySQL >> > PharoExtras / ODBC >> > DBXTalk / Garage >> > UDBC >> > UDBC2 >> > >> > 3) GitHub.io >> > >> > dbxtalk >> > >> > 4) GitHub >> > >> > pharo-rdbms/garage >> > >> > Now, let's say you picked one package. In some cases, if you are >> lucky, >> the code will load without any problem or warning. And then, you run the >> tests. That is where it almost *always* breaks! >> > >> > Today, I tried to load *each and everyone of them* in a Pharo 6.1 >> (Windows) image : none of them worked right out of the box! >> > >> > In other words, that newcomer I told you about just goes from "WOW!!!" >> to "WHAT?!?!" in 10 seconds. People are usually not so impressed with a >> TestRunner that fails a gazillion unit tests... >> > >> > So, now the nice part... >> > >> > Database connectivity is, in my humble opinion, a MUST for Pharo and >> Squeak. I think it's about time we do *something* about the current state >> of this mess. There are enough brilliant and talented people in the >> Squeak >> and Pharo communities to fix this situation. At least, we could start >> *talking* about it if we want to address the problems. Ideally, we would >> come up with a will to change things and establish a plan. >> > >> > In a perfect world, we'd have something like JDBC (or some kind of >> Smalltalk universal driver) in Smalltalk for native drivers. Plus ODBC >> connectivity. Plus it would have to work right-out-of-the-box. Plus >> documentation that has at least an example with >> Connect/SELECT/UPDATE/DELETE/CREATE/DROP/disconnect simple examples to >> get newbies started. Plus a solid suite of tests to beat the sh*t out of >> that code. Plus a compatibility layer for Squeak/Pharo differences. To >> that regard, Glorp is an example to follow! IMHO, it's about time we >> share >> stuff to maximize our efforts! >> > >> > As I told someone recently, it's about time we do something about >> databases (RDBMS). And as I told that person, I don't mind writing >> Smalltalk code and SQL scripts and running tests. Even do performance >> testing. My MySQL Server currently has close to 1 billion records to >> torture the MySQL driver if needed. And I can also work on SQLite. And >> Oracle. And DB/2. And MySQL Server. And I don't mind installing other >> RDBMS on my machine and test other driver ports. Now, it's just a matter >> of knowing if we all want to work together. >> > >> > As for OpenDBX/DBX, I'm not sure. Having another dependency (and C >> code) that we more or less control doesn't inspire me. I have yet to see >> how DBX/OpenDBX gives me any advantage over, say, ODBC... >> > >> > As I said, it's time to discuss! >> > >> > Anyone interested? >> > >> > ----------------- >> > BenoÃ®t St-Jean >> > Yahoo! Messenger: bstjean >> > Twitter: @BenLeChialeux >> > Pinterest: benoitstjean >> > Instagram: Chef_Benito >> > IRC: lamneth >> > Blogue: endormitoire.wordpress.com >> > "A standpoint is an intellectual horizon of radius zero". (A. >> Einstein) >> > >> > >> >> >> >> >> >> ---------- Forwarded message ---------- >> From: Sven Van Caekenberghe < > sven@ > > >> To: Moose-related development < > moose-dev@.unibe > > >> Cc: Pharo Development List < > pharo-dev@.pharo > >, Any question >> about pharo is welcome < > pharo-users@.pharo > > >> Bcc: >> Date: Mon, 15 Jan 2018 11:19:59 +0100 >> Subject: Re: [Pharo-users] [Moose-dev] [ann] gt connector >> >> >> > On 14 Jan 2018, at 22:54, Tudor Girba < > tudor@ > > wrote: >> > >> > Hi, >> > >> > Towards the end of last year we worked on GT Connector, a new kind of >> interface that allows us to exercise and test the limits (or the lack >> thereof) of Bloc. >> > >> > It looks like this: >> > > <connector2.jpeg> >> > >> > You can see it in action here: >> > https://twitter.com/feenkcom/status/936109463462965248 >> >> Incredible stuff ! >> >> Keep on pushing the boundaries. >> >> > In the current implementation, the Connector allows us to navigate and >> connect example methods. The focus is not on examples, but on the >> connections. We used examples because the engine was already around and >> offered us a nice use case. We want to extend it in the near future to >> other kinds of objects. >> > >> > There are a couple of things that are worth noting: >> > â¢ The editor works live, and the connection points appear and disappear >> as you type. >> > â¢ The layout of the editor elements is based on a tree-based graph >> layout that only works with constrains (no actual visible edges between >> the >> editor elements). >> > â¢ The editor works live, so adding new elements to the scene properly >> rearranges the scene. >> > â¢ But, perhaps, the most exciting part is the fact that the lines >> connect an element from inside the text editor element with another that >> lives outside of the editor element. >> > >> > All these validate the architecture of Bloc of having exactly one >> rendering tree. It was not an obvious goal a couple of years ago, but we >> are really happy that it works. >> > >> > To put it in perspective, let's compare this with the html world. Text >> is text is rendered through the DOM tree. If you want graphics you might >> use something like SVG which comes with its own tree. However, these are >> two distinct worlds, and you cannot go from one to another, or at least >> not >> easily. This is the case in most engines we looked at. >> > >> > Why is this important? One thing we learn in the Smalltalk world is >> that >> covering the same space with less concepts opens up a whole dimension of >> creativity that is simply not possible outside of it. >> > >> > The goal with Bloc is to enable new kinds of user interfaces. As we are >> late to the game of modern interfaces, even though the field was invented >> in Smalltalk, our only chance to take the lead again is to rethink the >> model. >> > >> > Let's look at the Connector again. In most user interfaces we have >> panes >> on the outside, and visuals confined within the boundaries of those >> panes. >> Interestingly, we can trace this pattern to the very first Smalltalk >> interfaces. In the Connector interface we have no boundaries with text >> and >> visualization being intertwined to form a new kind of workflow. >> > >> > Talking about workflows, we now have two distinct and novel ways to >> explore examples: one is Connector, and the other one is the expandable >> code editor. For example, the scene from above looks like this in the >> example expanding editor: >> > >> > > <editor.jpg> >> > >> > >> > Both of these interfaces are not found in other infrastructures, and >> yet >> they were both inexpensive to implement in Bloc. >> > >> > We believe this will have a deep impact for all sorts of interfaces, >> and >> especially for the IDE. If you are interested in more details related to >> the IDE, take a look at the following paper from 2015: >> > http://scg.unibe.ch/archive/papers/Girb15b- >> PervasiveSoftwareVisualizations.pdf >> > >> > Please let us know what you think. >> > >> > Cheers, >> > The feenk team >> > >> > >> > -- >> > www.tudorgirba.com >> > www.feenk.com >> > >> > "What is more important: To be happy, or to make happy?" >> > >> > _______________________________________________ >> > Moose-dev mailing list >> > > Moose-dev@.unibe >> > https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> >> >> >> >> ---------- Forwarded message ---------- >> From: Kjell Godo < > squeaklist@ > > >> To: Moose-related development < > moose-dev@.unibe > > >> Cc: Any question about pharo is welcome < > pharo-users@.pharo > >, >> Pharo Development List < > pharo-dev@.pharo > > >> Bcc: >> Date: Mon, 15 Jan 2018 10:44:26 +0000 >> Subject: Re: [Pharo-users] [Moose-dev] [ann] gt connector >> i want to use it >> >> >> ---------- Forwarded message ---------- >> From: Tudor Girba < > tudor@ > > >> To: Any question about pharo is welcome < > pharo-users@.pharo > > >> Cc: >> Bcc: >> Date: Mon, 15 Jan 2018 12:20:00 +0100 >> Subject: Re: [Pharo-users] [ANN] OpenSSL-Pharo works on Windows >> Thanks a lot! >> >> Doru >> >> >> > On Dec 20, 2017, at 8:55 AM, Pierce Ng < > pierce@ > > wrote: >> > >> > Hi all, >> > >> > OpenSSL-Pharo now works on Windows. Tested on Windows 10 with a fresh >> 32-bit >> > Pharo 6.1 zip package downloaded from pharo.org. On Windows this >> library uses >> > libeay.dll which is bundled with the Pharo VM. >> > >> > Metacello new >> > baseline: 'OpenSSL'; >> > smalltalkhubUser: 'PierceNg' project: 'OpenSSL-Pharo'; >> > load. >> > >> > Pierce >> > >> > >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "No matter how many recipes we know, we still value a chef." >> >> >> >> >> >> >> >> >> >> >> >> ---------- Forwarded message ---------- >> From: "Steffen MÃ¤rcker" < > merkste@ > > >> To: Any question about pharo is welcome < > pharo-users@.pharo > > >> Cc: >> Bcc: >> Date: Mon, 15 Jan 2018 12:27:06 +0100 >> Subject: [Pharo-users] Set Rounding mode for IEEE floating point >> operations >> Hi, >> >> is there any way to set the rounding mode for IEEE floating point >> operations? Maybe something like >> >> Double roundToMinusInfWhile: [... code goes here ...]Double >>> roundToZeroWhile: [... more code here ...] >>> >> >> If not, is it possible to add this behavior, e.g., via a custom >> primitive? >> >> Best, Steffen >> >> >> >> >> ---------- Forwarded message ---------- >> From: Petr Fischer < > petr.fischer@ > > >> To: > pharo-users@.pharo >> Cc: >> Bcc: >> Date: Mon, 15 Jan 2018 14:21:28 +0100 >> Subject: [Pharo-users] [Seaside] WAComponent instances tree + proper page >> refreshing for user (back button) - confusion >> Hello, sorry for crossposting (from Seaside list), but I probably do not >> understand something very basic in Seaside - how to properly refresh >> instantiated WAComponent tree (data views) and when (+ back button >> problems). >> >> Seaside manual says ("About Callbacks" section): >> >> "Do not change state while rendering... Just produce output and define >> callbacks that do the fancy stuff you canât do while rendering." >> >> OK, then my small example: >> >> 1) Suppose I have a page - WAMyListPage (WAComponent sub class), which >> presents a list of items from DB table, easy. >> >> 2) When WAMyListPage is instantiated at the beginnig, it loads 10 rows >> from the DB, creates WAMyItem (WAComponent subclass) for every DB row and >> puts these WAMyItem instances to the WAMyListPage instance variable >> "items" >> (OrderedCollection) >> >> 3) WAMyListPage is rendered to the browser (simple render call on all >> WAMyItem "items" components in a loop) - 10 items (db rows) are displayed >> - >> OK >> >> 4) User 1 clicks on the WAMyItem component from the rendered list (on the >> WAMyListPage) and goes into item detail page (detail page is not >> interesting here) >> >> 5) User 2 deletes 5 items/rows from the database (some way) >> >> 6) User 1 clicks browser back button and returns to the WAMyListPage, two >> cases can occur: >> >> A) typically, the "list page" is cached in the browser >> and >> browser immediatelly renders the list page from the cache (without >> request) >> - with all 10 old items (no refresh, broken old view with some non >> existing >> items) >> >> B) request from the browser to the Seaside app is made >> again (with old Seaside URL from browser history), then Seaside app just >> renders old state of WAMyListPage instance from the history and again - >> there is all 10 old WAMyItem items instantiated, so, broken again, old >> items in the view >> >> My question - where can I do a proper refresh of WAMyListPage list items? >> (manual refresh button in the Seaside app is unacceptable) >> >> Note: I can solve this by reloading WAMyListPage "items" instvar >> collection in every renderContentOn: (reload from DB, reload all WAMyItem >> instances) + instruct the browser to not cache any web page (in HTTP >> headers), so in point (6A) above, browser will ignore caching and make >> request to Seaside app again. >> In this way, everything works, WAMyListPage is actual every time, but >> main >> Seaside rule "Do not change state while rendering" is violated (WAMyItems >> are reinstantiated in every renderContentOn:). >> >> So, how do I face this? Thanks very much! pf >> >> >> >> _______________________________________________ >> Pharo-users mailing list >> > Pharo-users@.pharo >> http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org >> >> Ian Ian wrote > W.R.T Database Connectivity: > > Hi All, > > The database connectivity issue as discussed is near and dear to my > evaluation of Smalltalk(s). It is a huge problem/stumbling block as I see > it. > > Here Is a cut and paste of my replay to the Gemstone users group: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Hi Dale, > > I am evaluating Gemstone as an application server/big data repository. > Hence my confusion up till now. > > I work for an organization that has rather large data storage requirements > (understatement: into the 100's of petabyte range). > > Currently, several independent Apache Hadoop stacks are used to manage > this > data. There are several serious issues that are evident with this setup, > prime of which is object to relational mapping errors (as datasets in a > given space change over time - data is mandated to be kept into > perpetuity) > regardless of whether the database is NoSQL, SQL of any other schema. The > issue bubbles up into the organization application layers of many diverse > and distributed verticals. Maintenance of the system is not trivial and > is > very expensive and time consuming. > > We use virtualization (in the VMWare sense) to create views into the data. > Generally, access is a split between virtualized kiosk systems, another > level of indirection, where by mandate, we must now archive the state of > the vm's as well as business data, and direct workstation access, Not > fun, error prone and hardware intensive (from a data storage perspective). > > As I have been reading about object databases and what they are said to > buy > in terms of efficiency (objects being stored natively and directly) > coupled > with the fact the we are virtualizing everything we can, I, along with a > couple of colleagues, thought that we should take a look at what new > (laugh) technologies were available. > > After a little time I came across Gemstone. Did my reading and research > and after a period of semantic confusion (still going) became enamored > with > the possibilities. > > All this said, from a network, sys admin point of view, an image that > contains the application and it's objects is a godsend if object > persistence was guaranteed. It would allow me to archive a self contained > living blob that manages its own living state (in the VMWare snapshot > sense) and at the same time the data is available to other blobs/views > (seaside). > > On views in to the data store: > > Currently data mining occurs on the application layer (rather than > database > level views). Various development groups create views (applications) to > access (possibly update, if they are the owning group) the data. As > mandate trickle (waterfall) from above new data points can be added or > removed (some of the mandate for this is governed by changing regulations > - > in other words it must be done regardless of the technical difficulties > involved). You can image the difficulties and manpower involved. > > This brings me back to the application server. Currently, whatever tool a > group uses to access the data, be it browser, remote client application, > whatever have you (generally based on the skill sets in the group), > requires a set of policies and procedures wrapped around the effort > (mandated disaster recovery and etc...). Tones of work that can never be > standardized in any way but nevertheless must be documented and managed. > > Okay (to long winded self): > > Having spent some time looking at this problem from a smalltalk, image > virtualization, integrated application management perspective, all my > issues could be alleviated within a single technology. Yippee! > > The spawning of an idea: > > Amber -> Seaside -> Gemstone. One language (integrated properly -> one > tool). > > Amber: > > * Each group, with a small learning curve could create and manage their > own views into the data. > * The serialized javascript, once the client was developed, could be > streamed from the application server (Seaside/Gemstone) on demand. It > just > becomes another object. > > Seaside: > > * Client interface manager transport system (HTTP) for any and all views. > > Gemstone: > > * Object level persistence with no forced mappings of any kind. > * Extensibility. (can gemstone handle data levels in the petadata range?) > > Cool!: > > * Users/Developers of the system have a completely controlled view into > the > image/system (perhaps a clustered NginX front end?). > * Image access at the machine level is completely controlled/secure. > * Everything in one place with system knowledge transfer and expertise > leveraged vertically and horizontally. > * The images can easily be archived in whatever manner (at the bit level > using any version control system if desired) at whatever schedule. > * Another level of 'complete system' security achieved. (Way cool!!) > * Whole systems is a single entity! Fantastical! > * A significantly smaller foot print. > > * Cost reductions, increased efficiency all the way through... > > Pipe dream? Maybe but I think it is doable over time with smalltalk. The > same system is not doable in any other way with any other technology > without extensive dollars and effort and once built making dynamic > unplanned for changes virtually impossible. You are locked in (Silly but > happens all the time). With the system I envision, changes, even schema > changes, are relatively easy. > > For my money: > > * Gemtalk should integrate development tools directly into Gemstone > (Gemstone with seaside is an order of magnitude more useful than without > it) > * Gemtools should be in the reference client - Pharo - permanently > (CGI/RPC, everything). > What does the tODE buy me, other than access, but a shell? > Give Pharo a permanent seamless object store - make it easy for > me/others. The user base will grow. > Gemtalk will sell more licenses in the long run. > * Gemstone should be re-branded as a fully functional pure OO application > server with extensible secure persistence built in. (slight difference but > HUGE!!! - MS, in truth, is a marketing company) > Let's see if java can compete with that! (Not - they would be forced to > make changes just to try.) > * There are more but I am saying too much as it is.... > > Lastly, > > My proof of concept: > > 1. Create a seaside app > 2. Create its client in amber. > 3. Upload the client js to the stone. > 4. Stream the client(s) to the browser based on some form of uri > 5. Manipulated the data store (gemstone) with the client. > 6. Cluster the system. > 7. Develop a DR process. > 8. Sell it > > Should on the face of it be simple? > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > I know what this means for me as an evaluator of Smalltalk as a viable > system. I only include my response to that group to simply to show my > pain. > > The responses I got were on the order of 'you could do this,' or write > that... Neither answer, from my perspective is valid. > > I reiterate that Pharo with built in persistence as in a fully integrated > Gemstone is, IMHO, the best approach to take. The fact that gemstone as > the only non-flattened oo extensible database is sad. Worse is that > Gemtalk sees Gemstone as a separate entity. Object persistence requires > application level integration ie. gemstone requires you to develop your > app > and have it run in the stone in order to persist. The Gemtalk philosophy > is thus flawed on the face of it. > > I don't means to disparage anyone just stating facts as I see them. > > > > > > On 15 January 2018 at 08:22, < > pharo-users-request@.pharo > > wrote: > >> Send Pharo-users mailing list submissions to >> > pharo-users@.pharo >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.pharo.org/mailman/listinfo/pharo-users_ >> lists.pharo.org >> or, via email, send a message with subject or body 'help' to >> > pharo-users-request@.pharo >> >> You can reach the person managing the list at >> > pharo-users-owner@.pharo >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Pharo-users digest..." >> >> Today's Topics: >> >> 1. Re: Databases (Sven Van Caekenberghe) >> 2. Re: [Moose-dev] [ann] gt connector (Sven Van Caekenberghe) >> 3. Re: [Moose-dev] [ann] gt connector (Kjell Godo) >> 4. Re: [ANN] OpenSSL-Pharo works on Windows (Tudor Girba) >> 5. Set Rounding mode for IEEE floating point operations >> (Steffen M?rcker) >> 6. [Seaside] WAComponent instances tree + proper page refreshing >> for user (back button) - confusion (Petr Fischer) >> >> >> ---------- Forwarded message ---------- >> From: Sven Van Caekenberghe < > sven@ > > >> To: Benoit St-Jean < > bstjean@ > >, Any question about pharo is >> welcome < > pharo-users@.pharo > > >> Cc: >> Bcc: >> Date: Mon, 15 Jan 2018 10:55:04 +0100 >> Subject: Re: [Pharo-users] Databases >> BenoÃ®t, >> >> Yes, of course databases are important and I know many users ask for >> them, >> but on the other hand, the low development activity can only mean that >> there is not enough interest (or some existing solutions work well >> enough). >> >> There are many SQL and non-SQL databases out there, as well as many, >> incompatible Smalltalk implementations. I do not believe that there can >> be >> one magic solution to fix all problems everywhere. >> >> Remember that setting up a database is often a challenge by itself. >> >> I do not think the current situation is bad, it is just confusing. Making >> a good meta overview (i.e. documentation writing) and testing solutions >> would already help many people. >> >> To add to your list, I recently wrote a new PostgreSQL client, P3, that >> is >> using only TCP networking (no native library mess). It supports most >> recent >> Pharo distributions. >> >> https://github.com/svenvc/P3 >> >> P3 can be used under Glorp. Glorp in still being maintained and in active >> use, but could use some love in the promotion department. >> >> Here is some documentation >> >> http://files.pharo.org/books-pdfs/booklet-Glorp/2017-05-02- >> Glorp-Spiral.pdf >> https://medium.com/concerning-pharo/reddit-st-in-10-cool- >> pharo-classes-1b5327ca0740 >> https://github.com/SquareBracketAssociates/Booklet-Reddit (updated >> version of the former) >> https://bintray.com/squarebracketassociates/wip/download_file?file_path= >> reddit-wip.pdf >> >> Actually, few languages have as nice an Object Relational Mapper as >> Glorp. >> >> There is also Voyage that seems quite popular. >> >> Sven >> >> > On 15 Jan 2018, at 10:13, Benoit St-Jean via Pharo-users < >> > pharo-users@.pharo >> wrote: >> > >> > >> > From: Benoit St-Jean < > bstjean@ > > >> > Subject: Databases >> > Date: 15 January 2018 at 10:13:10 GMT+1 >> > To: " > pharo-users@.pharo > " < > pharo-users@.pharo > >, " >> > squeak-dev@.squeakfoundation > " <squeak-dev@lists. > > squeakfoundation.org> >> > Reply-To: Benoit St-Jean < > bstjean@ > > >> > >> > >> > Bear with me for a moment... >> > >> > First and foremost, this post is *not intended in any way* to criticize >> the work of anyone who could have worked on those >> packages/projects/frameworks. >> > >> > Now, I'll tell you a story to make my point. >> > >> > Often times, in public or in private, I help newcomers on Quora, IRC, >> the mailing list(s) or elsewhere with various Smalltalk environments. >> Often times, I try to be helpful getting them started on Squeak or Pharo. >> Often times, they are just amazed by how powerful Smalltalk is... >> > >> > Now, the sad part. Everything goes well until they just want to "code >> something" to experiment and they ask me about databases... >> > >> > -How can I connect to a MySQL (or insert your favorite database here) >> with Squeak/Pharo ? >> > >> > >> > As far as I can remember, the database connectivity with Squeak/Pharo >> has always been an area where, as a Squeak/Pharo community, we suck big >> time. I don't recall the last time I loaded a package, ran the tests and >> everything was fine. There is almost ALWAYS something broken with the >> databases packages. Understandibly, Squeak and Pharo were for a long >> time >> moving targets. Whether it was VM changes (FFI, NativeBoost, uFFI, 32 vs >> 64 bit, OS differences/problems, differences between Squeak and Pharo, >> etc), code refactoring (cryptography class name changes), the >> DateAndTime/Timestamp/TimeStamp/Date(Magnitude)/Date(Timespan) were used >> from one version to the other in the driver, code that was removed by >> some >> cleanup, compiler changes/problems/incompatibilities, etc. In other >> words, database connectivity needs some love. >> > >> > Unfortunately, it looks like there doesn't seem to be a consensus or a >> shared desire to fix things *together*. There is duplicate effort all >> over >> the place. Just as an example, I listed the various implementations of >> MySQL packages that exists (I did not list the 8-9 of them that had no >> code >> but a project listed on one of those sites). So, let's say you are a >> newcomer and you want to connect to a MySQL database. Here are the >> choices >> you are offered (and remember, as a newcomer, you have NO clue which one >> to >> pick) : >> > >> > >> > Databases supported : Project name >> > >> > 1) SqueakSource >> > >> > MySQL : Automatic Object Storage To MySQL >> > OpenDBX >> > SqueakDBX >> > >> > >> > 2) SmalltalkHub >> > >> > DBX/Talk / DBXDatabaseModel >> > GlorpDriverMySQL >> > PharoExtras / ODBC >> > DBXTalk / Garage >> > UDBC >> > UDBC2 >> > >> > 3) GitHub.io >> > >> > dbxtalk >> > >> > 4) GitHub >> > >> > pharo-rdbms/garage >> > >> > Now, let's say you picked one package. In some cases, if you are >> lucky, >> the code will load without any problem or warning. And then, you run the >> tests. That is where it almost *always* breaks! >> > >> > Today, I tried to load *each and everyone of them* in a Pharo 6.1 >> (Windows) image : none of them worked right out of the box! >> > >> > In other words, that newcomer I told you about just goes from "WOW!!!" >> to "WHAT?!?!" in 10 seconds. People are usually not so impressed with a >> TestRunner that fails a gazillion unit tests... >> > >> > So, now the nice part... >> > >> > Database connectivity is, in my humble opinion, a MUST for Pharo and >> Squeak. I think it's about time we do *something* about the current state >> of this mess. There are enough brilliant and talented people in the >> Squeak >> and Pharo communities to fix this situation. At least, we could start >> *talking* about it if we want to address the problems. Ideally, we would >> come up with a will to change things and establish a plan. >> > >> > In a perfect world, we'd have something like JDBC (or some kind of >> Smalltalk universal driver) in Smalltalk for native drivers. Plus ODBC >> connectivity. Plus it would have to work right-out-of-the-box. Plus >> documentation that has at least an example with >> Connect/SELECT/UPDATE/DELETE/CREATE/DROP/disconnect simple examples to >> get newbies started. Plus a solid suite of tests to beat the sh*t out of >> that code. Plus a compatibility layer for Squeak/Pharo differences. To >> that regard, Glorp is an example to follow! IMHO, it's about time we >> share >> stuff to maximize our efforts! >> > >> > As I told someone recently, it's about time we do something about >> databases (RDBMS). And as I told that person, I don't mind writing >> Smalltalk code and SQL scripts and running tests. Even do performance >> testing. My MySQL Server currently has close to 1 billion records to >> torture the MySQL driver if needed. And I can also work on SQLite. And >> Oracle. And DB/2. And MySQL Server. And I don't mind installing other >> RDBMS on my machine and test other driver ports. Now, it's just a matter >> of knowing if we all want to work together. >> > >> > As for OpenDBX/DBX, I'm not sure. Having another dependency (and C >> code) that we more or less control doesn't inspire me. I have yet to see >> how DBX/OpenDBX gives me any advantage over, say, ODBC... >> > >> > As I said, it's time to discuss! >> > >> > Anyone interested? >> > >> > ----------------- >> > BenoÃ®t St-Jean >> > Yahoo! Messenger: bstjean >> > Twitter: @BenLeChialeux >> > Pinterest: benoitstjean >> > Instagram: Chef_Benito >> > IRC: lamneth >> > Blogue: endormitoire.wordpress.com >> > "A standpoint is an intellectual horizon of radius zero". (A. >> Einstein) >> > >> > >> >> >> >> >> >> ---------- Forwarded message ---------- >> From: Sven Van Caekenberghe < > sven@ > > >> To: Moose-related development < > moose-dev@.unibe > > >> Cc: Pharo Development List < > pharo-dev@.pharo > >, Any question >> about pharo is welcome < > pharo-users@.pharo > > >> Bcc: >> Date: Mon, 15 Jan 2018 11:19:59 +0100 >> Subject: Re: [Pharo-users] [Moose-dev] [ann] gt connector >> >> >> > On 14 Jan 2018, at 22:54, Tudor Girba < > tudor@ > > wrote: >> > >> > Hi, >> > >> > Towards the end of last year we worked on GT Connector, a new kind of >> interface that allows us to exercise and test the limits (or the lack >> thereof) of Bloc. >> > >> > It looks like this: >> > > <connector2.jpeg> >> > >> > You can see it in action here: >> > https://twitter.com/feenkcom/status/936109463462965248 >> >> Incredible stuff ! >> >> Keep on pushing the boundaries. >> >> > In the current implementation, the Connector allows us to navigate and >> connect example methods. The focus is not on examples, but on the >> connections. We used examples because the engine was already around and >> offered us a nice use case. We want to extend it in the near future to >> other kinds of objects. >> > >> > There are a couple of things that are worth noting: >> > â¢ The editor works live, and the connection points appear and disappear >> as you type. >> > â¢ The layout of the editor elements is based on a tree-based graph >> layout that only works with constrains (no actual visible edges between >> the >> editor elements). >> > â¢ The editor works live, so adding new elements to the scene properly >> rearranges the scene. >> > â¢ But, perhaps, the most exciting part is the fact that the lines >> connect an element from inside the text editor element with another that >> lives outside of the editor element. >> > >> > All these validate the architecture of Bloc of having exactly one >> rendering tree. It was not an obvious goal a couple of years ago, but we >> are really happy that it works. >> > >> > To put it in perspective, let's compare this with the html world. Text >> is text is rendered through the DOM tree. If you want graphics you might >> use something like SVG which comes with its own tree. However, these are >> two distinct worlds, and you cannot go from one to another, or at least >> not >> easily. This is the case in most engines we looked at. >> > >> > Why is this important? One thing we learn in the Smalltalk world is >> that >> covering the same space with less concepts opens up a whole dimension of >> creativity that is simply not possible outside of it. >> > >> > The goal with Bloc is to enable new kinds of user interfaces. As we are >> late to the game of modern interfaces, even though the field was invented >> in Smalltalk, our only chance to take the lead again is to rethink the >> model. >> > >> > Let's look at the Connector again. In most user interfaces we have >> panes >> on the outside, and visuals confined within the boundaries of those >> panes. >> Interestingly, we can trace this pattern to the very first Smalltalk >> interfaces. In the Connector interface we have no boundaries with text >> and >> visualization being intertwined to form a new kind of workflow. >> > >> > Talking about workflows, we now have two distinct and novel ways to >> explore examples: one is Connector, and the other one is the expandable >> code editor. For example, the scene from above looks like this in the >> example expanding editor: >> > >> > > <editor.jpg> >> > >> > >> > Both of these interfaces are not found in other infrastructures, and >> yet >> they were both inexpensive to implement in Bloc. >> > >> > We believe this will have a deep impact for all sorts of interfaces, >> and >> especially for the IDE. If you are interested in more details related to >> the IDE, take a look at the following paper from 2015: >> > http://scg.unibe.ch/archive/papers/Girb15b- >> PervasiveSoftwareVisualizations.pdf >> > >> > Please let us know what you think. >> > >> > Cheers, >> > The feenk team >> > >> > >> > -- >> > www.tudorgirba.com >> > www.feenk.com >> > >> > "What is more important: To be happy, or to make happy?" >> > >> > _______________________________________________ >> > Moose-dev mailing list >> > > Moose-dev@.unibe >> > https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> >> >> >> >> ---------- Forwarded message ---------- >> From: Kjell Godo < > squeaklist@ > > >> To: Moose-related development < > moose-dev@.unibe > > >> Cc: Any question about pharo is welcome < > pharo-users@.pharo > >, >> Pharo Development List < > pharo-dev@.pharo > > >> Bcc: >> Date: Mon, 15 Jan 2018 10:44:26 +0000 >> Subject: Re: [Pharo-users] [Moose-dev] [ann] gt connector >> i want to use it >> >> >> ---------- Forwarded message ---------- >> From: Tudor Girba < > tudor@ > > >> To: Any question about pharo is welcome < > pharo-users@.pharo > > >> Cc: >> Bcc: >> Date: Mon, 15 Jan 2018 12:20:00 +0100 >> Subject: Re: [Pharo-users] [ANN] OpenSSL-Pharo works on Windows >> Thanks a lot! >> >> Doru >> >> >> > On Dec 20, 2017, at 8:55 AM, Pierce Ng < > pierce@ > > wrote: >> > >> > Hi all, >> > >> > OpenSSL-Pharo now works on Windows. Tested on Windows 10 with a fresh >> 32-bit >> > Pharo 6.1 zip package downloaded from pharo.org. On Windows this >> library uses >> > libeay.dll which is bundled with the Pharo VM. >> > >> > Metacello new >> > baseline: 'OpenSSL'; >> > smalltalkhubUser: 'PierceNg' project: 'OpenSSL-Pharo'; >> > load. >> > >> > Pierce >> > >> > >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "No matter how many recipes we know, we still value a chef." >> >> >> >> >> >> >> >> >> >> >> >> ---------- Forwarded message ---------- >> From: "Steffen MÃ¤rcker" < > merkste@ > > >> To: Any question about pharo is welcome < > pharo-users@.pharo > > >> Cc: >> Bcc: >> Date: Mon, 15 Jan 2018 12:27:06 +0100 >> Subject: [Pharo-users] Set Rounding mode for IEEE floating point >> operations >> Hi, >> >> is there any way to set the rounding mode for IEEE floating point >> operations? Maybe something like >> >> Double roundToMinusInfWhile: [... code goes here ...]Double >>> roundToZeroWhile: [... more code here ...] >>> >> >> If not, is it possible to add this behavior, e.g., via a custom >> primitive? >> >> Best, Steffen >> >> >> >> >> ---------- Forwarded message ---------- >> From: Petr Fischer < > petr.fischer@ > > >> To: > pharo-users@.pharo >> Cc: >> Bcc: >> Date: Mon, 15 Jan 2018 14:21:28 +0100 >> Subject: [Pharo-users] [Seaside] WAComponent instances tree + proper page >> refreshing for user (back button) - confusion >> Hello, sorry for crossposting (from Seaside list), but I probably do not >> understand something very basic in Seaside - how to properly refresh >> instantiated WAComponent tree (data views) and when (+ back button >> problems). >> >> Seaside manual says ("About Callbacks" section): >> >> "Do not change state while rendering... Just produce output and define >> callbacks that do the fancy stuff you canât do while rendering." >> >> OK, then my small example: >> >> 1) Suppose I have a page - WAMyListPage (WAComponent sub class), which >> presents a list of items from DB table, easy. >> >> 2) When WAMyListPage is instantiated at the beginnig, it loads 10 rows >> from the DB, creates WAMyItem (WAComponent subclass) for every DB row and >> puts these WAMyItem instances to the WAMyListPage instance variable >> "items" >> (OrderedCollection) >> >> 3) WAMyListPage is rendered to the browser (simple render call on all >> WAMyItem "items" components in a loop) - 10 items (db rows) are displayed >> - >> OK >> >> 4) User 1 clicks on the WAMyItem component from the rendered list (on the >> WAMyListPage) and goes into item detail page (detail page is not >> interesting here) >> >> 5) User 2 deletes 5 items/rows from the database (some way) >> >> 6) User 1 clicks browser back button and returns to the WAMyListPage, two >> cases can occur: >> >> A) typically, the "list page" is cached in the browser >> and >> browser immediatelly renders the list page from the cache (without >> request) >> - with all 10 old items (no refresh, broken old view with some non >> existing >> items) >> >> B) request from the browser to the Seaside app is made >> again (with old Seaside URL from browser history), then Seaside app just >> renders old state of WAMyListPage instance from the history and again - >> there is all 10 old WAMyItem items instantiated, so, broken again, old >> items in the view >> >> My question - where can I do a proper refresh of WAMyListPage list items? >> (manual refresh button in the Seaside app is unacceptable) >> >> Note: I can solve this by reloading WAMyListPage "items" instvar >> collection in every renderContentOn: (reload from DB, reload all WAMyItem >> instances) + instruct the browser to not cache any web page (in HTTP >> headers), so in point (6A) above, browser will ignore caching and make >> request to Seaside app again. >> In this way, everything works, WAMyListPage is actual every time, but >> main >> Seaside rule "Do not change state while rendering" is violated (WAMyItems >> are reinstantiated in every renderContentOn:). >> >> So, how do I face this? Thanks very much! pf >> >> >> >> _______________________________________________ >> Pharo-users mailing list >> > Pharo-users@.pharo >> http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 15, 2018

Re: [Pharo-users] [Moose-dev] [ann] gt connector

by Ben Coman

On 15 January 2018 at 05:54, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Towards the end of last year we worked on GT Connector, a new kind of > interface that allows us to exercise and test the limits (or the lack > thereof) of Bloc. > > It looks like this: > > You can see it in action here: > https://twitter.com/feenkcom/status/936109463462965248 > > In the current implementation, the Connector allows us to navigate and > connect example methods. The focus is not on examples, but on the > connections. We used examples because the engine was already around and > offered us a nice use case. We want to extend it in the near future to > other kinds of objects. > > There are a couple of things that are worth noting: > â¢ The editor works live, and the connection points appear and disappear as > you type. > â¢ The layout of the editor elements is based on a tree-based graph layout > that only works with constrains (no actual visible edges between the editor > elements). > â¢ The editor works live, so adding new elements to the scene properly > rearranges the scene. > â¢ But, perhaps, the most exciting part is the fact that the lines connect > an element from inside the text editor element with another that lives > outside of the editor element. > > All these validate the architecture of Bloc of having exactly one > rendering tree. It was not an obvious goal a couple of years ago, but we > are really happy that it works. > > To put it in perspective, let's compare this with the html world. Text is > text is rendered through the DOM tree. If you want graphics you might > use something like SVG which comes with its own tree. However, these are > two distinct worlds, and you cannot go from one to another, or at least > not easily. This is the case in most engines we looked at. > Thanks for this review. Its good to get a peek behind the curtain to understand what has been learnt (wrong and right) that feeds into the design. > > Why is this important? One thing we learn in the Smalltalk world is that > covering the same space with less concepts opens up a whole dimension > of creativity that is simply not possible outside of it. > > The goal with Bloc is to enable new kinds of user interfaces. As we are > late to the game of modern interfaces, even though the field was invented > in Smalltalk, our only chance to take the lead again is to rethink the > model. > > Let's look at the Connector again. In most user interfaces we have panes > on the outside, and visuals confined within the boundaries of those > panes. Interestingly, we can trace this pattern to the very first Smalltalk > interfaces. In the Connector interface we have no boundaries with text > and visualization being intertwined to form a new kind of workflow. > > Talking about workflows, we now have two distinct and novel ways to > explore examples: one is Connector, and the other one is the expandable > code editor. For example, the scene from above looks like this in the > example expanding editor: > > > > > Both of these interfaces are not found in other infrastructures, and yet > they were both inexpensive to implement in Bloc. > This is fantastic. I dreamed a little of such an interface. Another good example would be a deep expansion of "super initialize". I guess this works easiest with "self" and "super" since there is only one method to expand. For message chains or where messages are sent to variables and multiple implementors need to be considered, it might not be completely practical but still a cool demonstration to have horizontally scrolling of multiple methods - similar to GTInspector panes scroll horizontally. cheers -ben > > We believe this will have a deep impact for all sorts of interfaces, and > especially for the IDE. If you are interested in more details related to > the IDE, take a look at the following paper from 2015: > http://scg.unibe.ch/archive/papers/Girb15b-PervasiveSoftwareVisualization > s.pdf > > Please let us know what you think. > > Cheers, > The feenk team >

Jan. 15, 2018

Re: [Pharo-users] How to declare a do:[] loop for a matrix to read and acces its elements?

by Nicolai Hess

2018-01-15 18:04 GMT+01:00 Photon <nico-braun(a)live.de>: > when I call the countNeighbours method i get an error: the block wants two > arguments but I pass only one. > This is probally because i want to pass x y but only really pass x wich > ends > up being a cell and not the index. > > I still have trouble thinking it trough. The indicieDo: method seems to > make > the matrix bigger?! I don`t quite understand it. > It should not, and looking at the implementation, it just iterates with two loops 1 to number of rows times 1 to number of columns and calls your block argument with the pair of indexes. > > There must be an easy way to to figure out if the suroundings are alive or > not. I mean its all there what I need and in my mind its so easy to > discribe > it with normal words. But to tell the machine witth syntax is another thing > really :/ > About the surroundings, there is a nice method in Point Point>>eightNeighbors, that gives you the coordinates of the eight surrounding fields for example: (5@7) eightNeighbors "{(6@7). (6@8). (5@8). (4@8). (4@7). (4@6). (5@6). (6@6)}" with this method and if you iterate through all pairs of indices of the matrix, you can do your computation for every point, but you have to take care about the points that don't have valid matrix indices for some of their neighbours (like 0@0, the left and top neighbours may actually "on the other side of the matrix"). But you can take a look at SequenceableCollection>>atWrap: how it deals with "wrapping around". > > what if i selected only one element with do:[] and let its tell me its > idices. I store them in a temp object and then I check outside the block > the > neighbours and add to the counter. Once this is done I repeat as many times > as their elements in the matrix? > > Greetings > > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Jan. 15, 2018

← Newer
1
...
23
24
25
26
27
28
29
...
46
Older →

Jump to page: