- Pharo-users - lists.pharo.org

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

by Photon

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. 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 :/ 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

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

by Glenn Hoetker

Wow! This is really cool and has lots of potential use cases. Being able to navigate through classes and their methods this way would be especially helpful in overcoming what Iâve found to be a challenge in Smalltalk. On the one hand, the practice of breaking code into many small methods, each with a single discrete function, offers some real advantages once you get used to it. On the other hand, it does make it harder to understand the gestalt of a class, relative to having everything in a single text file you can just scan through. Lots of pointing & clicking in the system browser, with it being hard to see everything at once. But...being able to have a class, the methods I particularly care about at the moment and the connections between them all visible on the screen at once would be absolutely awesome. It is also something that Smalltalk is uniquely able to offer. Cool! Sent from my iPad > On Jan 15, 2018, at 8:41 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Impressive!! > > Would be used for a visual implementer/sender browser > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Jan 14, 2018, at 6:54 PM, 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: >> <connector2.jpeg> >> >> 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: >> >> <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.… >> >> 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(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >

Jan. 15, 2018

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

by Photon

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. 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 :/ 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

Jan. 15, 2018

Re: [Pharo-users] [ANN] OpenSSL-Pharo works on Windows

by Francisco Ortiz PeÃ±aloza

Thanks! Francisco On Mon, Jan 15, 2018 at 8:20 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Thanks a lot! > > Doru > > > > On Dec 20, 2017, at 8:55 AM, Pierce Ng <pierce(a)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. 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." > > > > > > > > >

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 15:29 GMT+01:00 Photon <nico-braun(a)live.de>: > Hello folks, > > I am trying since yesterday to make a game of life implemenation work. It > looks all ok so far but in can`t figure out the final steps. I think I get > the logic I have to use and if I imagine the code in C++ for example it > would be pretty much straight forward. But with pharo I got trouble telling > the machine what I want. > > In short I`m trying to make this method work: > > > > I wrote a test wich looks like this: > > > > I want to go trough each element of the matrix(cells), check its surounding > cells if they are alive, and set its counter if there are any living > neighbours. It should move like this through the whole matrix to set the > neighbour counter for each element. > > In this method i just tried the implement the topLeft check yet but I think > you get the idea. You can look at the comment in the top section it shows > where the neighbour indexes are. > > I tried so many things by now, did research read methods of the > superclasses > but I can`t make it work. > I woud be really glad if someone gave me a little hint. What is wrong here? > I Photon, what exaclty get wrong ? Do you have an error message or is just the result not what you expected? Iterating over a matrix with do: would iterate over the whole contents of the matrix and the do block gets only called with a single value (the actual element). If you want to iterate over the indices (x/y) you can take a look at the method Matrix>>indicesDo: . Or if it does not match what you are looking for, check out the other methods in Matrix 'enumeration' protocol. nicolai > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Jan. 15, 2018

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

by Alexandre Bergel

Impressive!! Would be used for a visual implementer/sender browser Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jan 14, 2018, at 6:54 PM, 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: > <connector2.jpeg> > > You can see it in action here: > https://twitter.com/feenkcom/status/936109463462965248 <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: > > <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.… > > 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(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Jan. 15, 2018

Re: [Pharo-users] Databases

by Sven Van Caekenberghe

> On 15 Jan 2018, at 16:34, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > 2018-01-15 12:25 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > >>> On 15 Jan 2018, at 10:55, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>> To add to your list, I recently wrote a new PostgreSQL client, P3, that is using only TCP networking (no native library mess). >> >> Another important advantage of a TCP/IP based database client is that outstanding/long-running calls do not block your image. > > I think thas has more to do with the way FFI calls work in Pharo > rather than TCP/IP. > I.e. Dolphin Smalltalk had the option of non-blocking FFI, used > extensively for DB access where there is more wait and transfer state, > than execution. Yes, of course, it is not impossible, just much harder to get right. With networking you get this basically for free.

Jan. 15, 2018

Re: [Pharo-users] Databases

by Esteban A. Maringolo

2018-01-15 12:25 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> On 15 Jan 2018, at 10:55, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> To add to your list, I recently wrote a new PostgreSQL client, P3, that is using only TCP networking (no native library mess). > > Another important advantage of a TCP/IP based database client is that outstanding/long-running calls do not block your image. I think thas has more to do with the way FFI calls work in Pharo rather than TCP/IP. I.e. Dolphin Smalltalk had the option of non-blocking FFI, used extensively for DB access where there is more wait and transfer state, than execution. Esteban A. Maringolo

Jan. 15, 2018

Re: [Pharo-users] Databases

by Sven Van Caekenberghe

> On 15 Jan 2018, at 10:55, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 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). Another important advantage of a TCP/IP based database client is that outstanding/long-running calls do not block your image. > 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-1b53… > https://github.com/SquareBracketAssociates/Booklet-Reddit (updated version of the former) > 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> wrote: >> >> >> From: Benoit St-Jean <bstjean(a)yahoo.com> >> Subject: Databases >> Date: 15 January 2018 at 10:13:10 GMT+1 >> 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> >> Reply-To: Benoit St-Jean <bstjean(a)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 >> "A standpoint is an intellectual horizon of radius zero". (A. Einstein) >> >> >

Jan. 15, 2018

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

by Photon

Hello folks, I am trying since yesterday to make a game of life implemenation work. It looks all ok so far but in can`t figure out the final steps. I think I get the logic I have to use and if I imagine the code in C++ for example it would be pretty much straight forward. But with pharo I got trouble telling the machine what I want. In short I`m trying to make this method work: I wrote a test wich looks like this: I want to go trough each element of the matrix(cells), check its surounding cells if they are alive, and set its counter if there are any living neighbours. It should move like this through the whole matrix to set the neighbour counter for each element. In this method i just tried the implement the topLeft check yet but I think you get the idea. You can look at the comment in the top section it shows where the neighbour indexes are. I tried so many things by now, did research read methods of the superclasses but I can`t make it work. I woud be really glad if someone gave me a little hint. What is wrong here? -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 15, 2018