- Pharo-users - lists.pharo.org

Pharo on my Ubuntu laptop :3

by CodeDmitry

Behold! <http://forum.world.st/file/n4917833/UZiJpUz.png> -- View this message in context: http://forum.world.st/Pharo-on-my-Ubuntu-laptop-3-tp4917833.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Oct. 3, 2016

Re: [Pharo-users] About Seaside3.2

by Stephan Eggermont

On 01/10/16 07:45, stepharo wrote: > And it is proposing the correct menu? > And how do I know that this 3.2.0? We have a comprehensive site: https://github.com/SeasideSt/Seaside/wiki/Seaside320Changelog Or you don't and then you take a look at the symbolic versions and select one of those, either #'stable' or #'release3.2'. > In my version that I took from latest ci there is not Zn*adaptor That is a bug we'd need to fix. Core developers and most users use specific configurations that use seaside groups, not the default group. Stephan

Oct. 3, 2016

Pharo Association

by John Pfersich

I went to the Pharo Association web site (http://association.pharo.org) to change my profile, but I didn't find any way to alter it. Am I missing something? Sent from my iPad

Oct. 3, 2016

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

by stepharo

+1 We want to support Windows! But ... 64 bits, FFI++, ARM ... well you know. Gimme 10 Millions or just one million and the situation will be really different. Stef >> By the way I am all for COM for Pharo, the issue is that 2/3 of our >> community are MacOS and Linux users , I dont even remember the last time we >> had a Windows only topic in the mailing list. Modern languages generally >> avoid using OS specific libraries, the last exceptions be C# and Swift and >> C# definetly looks like it will be fully cross platform soon enough (it >> already is because of Mono). > I wouldn't state such affirmations without a proper surveying. > > My latest survey related with RDBMS support [1] showed that the users > of Windows are on par with the users of MacOS. > > I am a Windows user, who runs most of the Pharo images inside Linux > VMs not because I don't want to run them in Windows, but because the > current support of Windows is somewhat limited. > > Having COM support for Pharo in a Windows environment would be a big > enabler to a lot of current users of Smalltalk that don't use Pharo. > > Esteban A. Maringolo > > [1] https://medium.com/@emaringolo/pharo-rdbms-support-survey-results-9c8f64087… > >

Oct. 3, 2016

Re: [Pharo-users] Glorp

by stepharo

Ahhhhh tx for the explanation. I'm sure that I like bundles for the sake of them. >> should not we removed DBXGlorp if it is not up to date? >> >> Is BDXGlorp based on latest Glorp port? > GlorpDBX is nothing but a name to a Metacello config that used to load > both Glorp and the OpenDBX (now garageDB) drivers. > > > Esteban A. Maringolo > >

Oct. 3, 2016

Re: [Pharo-users] bytes to utf8 string / byte stream parsing

by stepharo

Hello Fabrice Did you read the excellent book chapter written by sven on stream encodings? Check Enterprise Pharo book http://books.pharo.org Now can you tell us what you want to do? It would be nice also to check if Xtreams offers (or deserves some extensions). Stef Le 30/9/16 Ã 12:57, Fabrice Leal a Ã©crit : > can anyone provide me some pointers on how to turn a bunch of bytes > into a utf8 string? > > i'm planning on writing a byte stream parser, would appreciate > anything you might find useful in addition to the Streams chapter from > Pharo by Example > > -- > --- > Fabrice Leal

Oct. 3, 2016

Re: [Pharo-users] Get implementors list window from Spotter

by stepharo

Me too ;) I thought that I was the only one not being able to use Spotter :) > I meant to add, in practice what I find happened is that I use Spotter > to do initial search for implementors, then I randomly select onne of > the so that I can do ctrl-M to get to the ImplementorsOf dialog. It > would be nice to skip that intermediate step. > >> cheers -ben >

Oct. 3, 2016

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

by Ben Coman

On Mon, Oct 3, 2016 at 2:52 AM, CodeDmitry <dimamakhnin(a)gmail.com> wrote: > @kilon.alios > > [1] > I like C++/CLI more than C# because it is very refreshing to use a > language capable of using managed memory and unmanaged memory. > > I am too used to being in languages where garbage collection is > forced on you and everything must be done via new or stack types > such as Java, most scripting languages; > Or using languages where static-types are forced on you and > heavily encouraged over dynamic types. > > I feel very "free" when I write C++CLI, as it can do everything > C# can(although many things are admitably harder), but it can also > call C when it feels like it. > > [2] > If you want to get more users, I hope you are checking the things > people are saying about Smalltalk. > > In my class last week, the general concensus was that > "Smalltalk is dead, why are we studying this useless language". This article is about Lisp, but the same applies to Smalltalk... http://www.paulgraham.com/avg.html University is not just about spitting you out able to operate the latest fashionable tools, which may change in five years anyway. Its about *stretching* your mind in different directions by exposure to *different* paradigms. Smalltalk's immersive programming within an environment of live and persistent objects is about as different as you can get from the conventional file based programming. If they've not grokked this "blub" aspect of Smalltalk due to short-sighted negative approach then they are missing a learning opportunity. After University, work/life pressures provide less opportunity to learn such different paradigms - so you may be forever blind to them. The only languages worth learning are those that change the way you *think* about programming. As for why Smalltalk didn't hit mainstream yet? It seems more a failure of business strategy than technical fundamentals in a time when the Internet was changing the nature of the world - including programming with free tools and open source collaboration. http://c2.com/cgi/wiki?WhyIsSmalltalkDead > > Personally, I really enjoy the environment, but I feel that the > environment would do better from giving existing users a reason > to tell their friends about Pharo, and to like the language. > > There are many things that relate to this > > 1. Reasons to be excited about Pharo/Smalltalk > - It is a system where you can modify the system within the system. > - It has a very simple syntax, which is capable of doing things as > powerful as JavaScript. > - It is easy to get on Windows(3 minute download self contained)... > - It has pretty powerful prototyping means, but it's not quite as > powerful as > it could be. One way to improve this would be to add a morph editor > similar to > VB6. Morphs are somewhat scary to new users right now, and I feel they > stand a bit > further than where AWT/Swing is in terms of difficulty getting > started, even > if it is not necessarily true. > > 2. Quality of Life > - Blocks the GUI thread in strange scenarios: It's really aggrevating > when > it does this; when you type in code, the GUI should not freeze! > - Make it a bit easier to remove morphs(Pit of least astonishment, shift > alt click > is not obvious, and morph that consists of many morphs is somewhat > hard to select > the parent morph, so you have to delete the child morph then shift alt > click the > same place to select the underlying morph(eg grids). > - More themes! > - I know you're going to hate me for this but... It's a bit annoying to > install > Pharo on 64-bit Linux right now... This is a high priority and a 64-bit is imminent. > - It is kind-of hard to understand what .image, .changes, and .sources > are and > the material online isn't very exhaustive on their responsibilities. > To date I > am not actually sure what purpose .sources serves. For each Pharo Release the .changes file that has been running during development is condensed to a static .sources file, so that the Release has an empty .changes files. So only user changes show up in .changes. > - It's too easy to put Pharo into inconsistant state where it harasses > you with > popups. It should be easier to access the "undo whatever I just did > please", whether > it is editing of code, or running a code, I am not sure how easy this > is but at the > moment, it's not as up-front as it could be; It's scary when you do > something and > your environment starts yelling at you. (Maybe we could use some > Toasts instead of > Popups?). With great power comes great responsibility ;) Yes it can be tough as a newcomer when you don't know where the traps are. Something more to help recovery would be useful. > - Is there a Pharo alternative to JavaScript timeouts? Can you describe Javascript timeouts? > > That is all I could think of for now, probably not going to help you much > but I wanted > to give my 1/1000 of a cent. Thanks for your feedback. It is good to get a newcomers perspective. Some of these are know issues that we get used to and work around because we balance them off against other "blub" benefits of the environment, which newcomers might not stick around long enough to discover if the entry friction is too high. cheers -ben

Oct. 3, 2016

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

by phil＠highoctane.be

Ok. Fine points. Want to contribute? Easy: https://pharo.fogbugz.com/ Even more easy: join the association @ http://association.pharo.org/ Being using it for serious stuff and make money out of it? Join the consortium : http://consortium.pharo.org/ Discover some little interesting gem or way to do things in it? Tweet with #Pharo. https://twitter.com/search?q=%23Pharo (more people should do this actually). Use it whenever you can, it will force you to understand how to do real stuff with it properly. I do hackathons with it. https://hackernoon.com/hackapost-how-hackathons-can-be-the-best-learning-to… I do use it to do things for customers and whoever could benefit. I just crafted a little tool to produce summary tables for a school this week. They were doing this computation by hand or using they somewhat basic Excel skills. Key important thing: no complications to install that on a Windows box: unzip folder, run Pharo. Net result: good karma. I now of no other platform where you can get something you make an easy to integrate part (if not in the core, in a package/configuration). This community is smaller, contributors can actually make a difference. Think about how it makes you feel: valued. Not yet another package in a sea of packages. If I were to listen what other people do, yeah, one day Scala, the next Python, the next Angular(2), React, Node, Electron, Swift, C#, not to mention the Hadoop bestiary ... this is a neverending stream of ever switching tech. It will not stop. [I am using these things for real projects mind you - https://proba-v-mep.esa.int/ is what I am busy with half my weeks]. How does one develop a true solid understanding of the underlying fundamentals? With Pharo you actually can. Can see how parsing works (PetitParser), can see how VM works (read Clement Bera blog and write your little VM thingy), can see how a click become an event and actually craft nifty little tools, look into VM plugins and see how something is done in various major platforms, ...). We are not just *using* what vendors throw at us. We are actually able to go to the next level. The price for that freedom is present. But it gives a better appreciation of the whole picture. You sound like a fine fellow, so, welcome aboard and help us make this thing rock even more. Phil On Sun, Oct 2, 2016 at 10:38 PM, CodeDmitry <dimamakhnin(a)gmail.com> wrote: > Contribution is something I've been thinking about for quite some time > because it's interesting how a lot of software is declared "open" but make > it not obvious what you can do to help, or at least participate, or just > take a glimpse at the code to see if something stands out. > > I am a believer that there is a way to structure a project in a way to make > it very easy for people with decent experience in broad programming > paradigms to jump into looking over your code and propose revisions or > question design decisions. > > That said, I've also been in groups where people only want to write things > once and forget it exists and can't handle any criticism and consider any > questions asked to them as a waste of time, who will only work on stuff > at last moment and won't let anybody help them. > > The factors I've noticed are: > > 1. Ease of finding the repositories which you want people to contribute to, > and tell them apart from > repositories which you don't want people to contribute to, or are > irrelevant > to the project(often a project > is broken down into multiple repositories, and the dependency chain isn't > clear). > > 2. Dependencies: If you ever took a look at a Minix Kernel, you will notice > a huge chain of headers > including headers including headers, scopes with over 7 variables in them, > and nonflat hierarchies which > look at multiple include directories, many of which are not even part of > the > project, eg Minix will look at > the system's include directory to decide things rather than figure it out > in > a standalone way. This means > that it is very hard to just take things out of context and understand them > without traversing huge > dependency chains, this really discourages contribution. > > 3. Strict coding guidelines: i've seen projects that force you to either > use > tabs, or only use spaces, or such. These are very harmful to encouraging as > many people to participate as possible; we have tools > to restructure code you are looking at automatically, but these tools are > not very easy to access on > all platforms, and need to be configured to your tastes. These tools > improve > productivity immensely but > people need to be told how to use them. > > 4. Ease of telling "where is the start" "where is the end". Many projects > are simply too hard to tell where the start/where the end is, and where the > plugins are, etc. Making it clear where the VM start point is, and > how the project is structured, how the dependency chain looks like really > helps familiarize yourself faster, > and lets people jump into contributing faster as they don't feel like they > need to learn EVERYTHING > before doing anything. > > ---- > > My argument is: > Let S be the set of all people who are aware of Pharo's existence who have > enough > programming experience to be relevant to possibly contributing. > > Let C be the set of all the people in S who have an interest in > contributing > to Pharo, or are willing to contribute to Pharo if you were to come up to > them and ask them to sit next to you and work on it with you. eg they have > the time/resources but don't feel like they go out of their way to get > started. > > Let N be the set of all the people in C who are actually contributing or > will contribute to Pharo at some point. > > There exists a way to structure the project under a philosophy which, the > closer you come to it, > the more set N decreases, that is, if the philosophy is executed perfectly, > there are no people who are > capable of contributing something relevant, who have not done so or will > never do so. > > I am not quite sure what the exhaustive philosophy is, but I suspect the > factors up front play a part in it. > > > > > > -- > View this message in context: http://forum.world.st/Intro- > to-Microsoft-COM-for-Smalltalkers-tp4917738p4917793.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > >

Oct. 2, 2016

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

by Dimitris Chloupis

you dont need to have a lot of experience to contribute, even with zero experience as a coder if you understand the basics you can at least contribute class comments. Contribution wise Pharo is quite flexible and if one is lost in the process people are more than happy to help him/her out. When I helped a Pharo student to learn , she was really suprised that I was so helpful but on the other hand when I joined the community people really helped me out understanding Pharo and answered even my most irrelevant questions. Plus even if you just want to create your own libraries as long as you share them you still contributing enough. None will stop you from following your own design principles , Pharo developers made it even very easy to make your project to be installed with a single click directly from inside the image via Package Browser. This is actually one of the big strengths of Pharo that has made contributions so easy. On Sun, Oct 2, 2016 at 11:45 PM CodeDmitry <dimamakhnin(a)gmail.com> wrote: > Contribution is something I've been thinking about for quite some time > because it's interesting how a lot of software is declared "open" but make > it not obvious what you can do to help, or at least participate, or just > take a glimpse at the code to see if something stands out. > > I am a believer that there is a way to structure a project in a way to make > it very easy for people with decent experience in broad programming > paradigms to jump into looking over your code and propose revisions or > question design decisions. > > That said, I've also been in groups where people only want to write things > once and forget it exists and can't handle any criticism and consider any > questions asked to them as a waste of time, who will only work on stuff > at last moment and won't let anybody help them. > > The factors I've noticed are: > > 1. Ease of finding the repositories which you want people to contribute to, > and tell them apart from > repositories which you don't want people to contribute to, or are > irrelevant > to the project(often a project > is broken down into multiple repositories, and the dependency chain isn't > clear). > > 2. Dependencies: If you ever took a look at a Minix Kernel, you will notice > a huge chain of headers > including headers including headers, scopes with over 7 variables in them, > and nonflat hierarchies which > look at multiple include directories, many of which are not even part of > the > project, eg Minix will look at > the system's include directory to decide things rather than figure it out > in > a standalone way. This means > that it is very hard to just take things out of context and understand them > without traversing huge > dependency chains, this really discourages contribution. > > 3. Strict coding guidelines: i've seen projects that force you to either > use > tabs, or only use spaces, or such. These are very harmful to encouraging as > many people to participate as possible; we have tools > to restructure code you are looking at automatically, but these tools are > not very easy to access on > all platforms, and need to be configured to your tastes. These tools > improve > productivity immensely but > people need to be told how to use them. > > 4. Ease of telling "where is the start" "where is the end". Many projects > are simply too hard to tell where the start/where the end is, and where the > plugins are, etc. Making it clear where the VM start point is, and > how the project is structured, how the dependency chain looks like really > helps familiarize yourself faster, > and lets people jump into contributing faster as they don't feel like they > need to learn EVERYTHING > before doing anything. > > ---- > > My argument is: > Let S be the set of all people who are aware of Pharo's existence who have > enough > programming experience to be relevant to possibly contributing. > > Let C be the set of all the people in S who have an interest in > contributing > to Pharo, or are willing to contribute to Pharo if you were to come up to > them and ask them to sit next to you and work on it with you. eg they have > the time/resources but don't feel like they go out of their way to get > started. > > Let N be the set of all the people in C who are actually contributing or > will contribute to Pharo at some point. > > There exists a way to structure the project under a philosophy which, the > closer you come to it, > the more set N decreases, that is, if the philosophy is executed perfectly, > there are no people who are > capable of contributing something relevant, who have not done so or will > never do so. > > I am not quite sure what the exhaustive philosophy is, but I suspect the > factors up front play a part in it. > > > > > > -- > View this message in context: > http://forum.world.st/Intro-to-Microsoft-COM-for-Smalltalkers-tp4917738p491… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Oct. 2, 2016