Re: [Pharo-users] Video Tutorials about Pharo
Very nice! I will watch them all… On 26 Apr 2014, at 20:16, kilon alios wrote: > Hello pharoers . I have created a playlist in youtube where in the past few > days I am keep adding new tutorials about the basics of Pharo. > > https://www.youtube.com/watch?v=Ol5ivaEATLQ&list=PLqbtQ7OkSta0ULYAd7Qdxof851ybh-_m_ > > For now I am focusing on the vary basics. So far the tutorials are > > 1) Why Pharo -> Explaining why I love Pharo and what Pharo is. > 2) Install Pharo > 3) Create a Class > 4) Workspace Variables > 5) Instance Variables > 6) Temporary Variables > > I try to keep the duration at most around 10 minutes , if I can around 3-4 > minutes. My goals is to focus on one or two features per tutorial. > > My focus for now is explaining the basics of Pharo the Language and Pharo the > IDE. I hope however that after that I will have the energy and time to focus > on Pharo libraries, like Nativeboost, Athens, Roosal , Sockets and many more. > > If my free time holds and I do not run out of steam, I should be able to > produce around 30 - 60 hours per year of Video Tutorials that will be able to > document a ton of Pharo functionality. > > Already the Playlist is over an hour long and I try to keep my tutorials > focused entirely on the practical side. > > Your comments and support is greatly appreciated.
Re: [Pharo-users] Video Tutorials about Pharo
Very nice initiative, keep it on! :) On Apr 27, 2014 10:45 AM, "Marcus Denker" wrote: > Very nice! I will watch them all… > > On 26 Apr 2014, at 20:16, kilon alios wrote: > > Hello pharoers . I have created a playlist in youtube where in the past > few days I am keep adding new tutorials about the basics of Pharo. > > > https://www.youtube.com/watch?v=Ol5ivaEATLQ&list=PLqbtQ7OkSta0ULYAd7Qdxof851ybh-_m_ > > For now I am focusing on the vary basics. So far the tutorials are > > 1) Why Pharo -> Explaining why I love Pharo and what Pharo is. > 2) Install Pharo > 3) Create a Class > 4) Workspace Variables > 5) Instance Variables > 6) Temporary Variables > > I try to keep the duration at most around 10 minutes , if I can around 3-4 > minutes. My goals is to focus on one or two features per tutorial. > > My focus for now is explaining the basics of Pharo the Language and Pharo > the IDE. I hope however that after that I will have the energy and time to > focus on Pharo libraries, like Nativeboost, Athens, Roosal , Sockets and > many more. > > If my free time holds and I do not run out of steam, I should be able to > produce around 30 - 60 hours per year of Video Tutorials that will be able > to document a ton of Pharo functionality. > > Already the Playlist is over an hour long and I try to keep my tutorials > focused entirely on the practical side. > > Your comments and support is greatly appreciated. > > >
Re: [Pharo-users] Video Tutorials about Pharo
+1 Doru On Sun, Apr 27, 2014 at 11:54 AM, Bernat Romagosa < tibabenfortlapala...@gmail.com> wrote: > Very nice initiative, keep it on! :) > On Apr 27, 2014 10:45 AM, "Marcus Denker" wrote: > >> Very nice! I will watch them all… >> >> On 26 Apr 2014, at 20:16, kilon alios wrote: >> >> Hello pharoers . I have created a playlist in youtube where in the past >> few days I am keep adding new tutorials about the basics of Pharo. >> >> >> https://www.youtube.com/watch?v=Ol5ivaEATLQ&list=PLqbtQ7OkSta0ULYAd7Qdxof851ybh-_m_ >> >> For now I am focusing on the vary basics. So far the tutorials are >> >> 1) Why Pharo -> Explaining why I love Pharo and what Pharo is. >> 2) Install Pharo >> 3) Create a Class >> 4) Workspace Variables >> 5) Instance Variables >> 6) Temporary Variables >> >> I try to keep the duration at most around 10 minutes , if I can around >> 3-4 minutes. My goals is to focus on one or two features per tutorial. >> >> My focus for now is explaining the basics of Pharo the Language and Pharo >> the IDE. I hope however that after that I will have the energy and time to >> focus on Pharo libraries, like Nativeboost, Athens, Roosal , Sockets and >> many more. >> >> If my free time holds and I do not run out of steam, I should be able to >> produce around 30 - 60 hours per year of Video Tutorials that will be able >> to document a ton of Pharo functionality. >> >> Already the Playlist is over an hour long and I try to keep my tutorials >> focused entirely on the practical side. >> >> Your comments and support is greatly appreciated. >> >> >> -- www.tudorgirba.com "Every thing has its own flow"
Re: [Pharo-users] [ANN] JNIPort for Pharo 3.0 alpha
2014-04-08 16:04 GMT-03:00 Pharo4Stef : > In VW there is the concept of object bodies and head now we will eventually > have that with Spur. Maybe clement explained it somewhere in his blog (I > understood the point once and of course I forgot). > > Now I wonder what changed so much between 1.2 and 3.0 Dolphin's #become: uses the same concept. E.g. a become: b Doesn't switch references, but instead "body" pointers in a and b. It is, a becomes b, and b becomes a. i Time microsecondsToRun: [1000 timesRepeat: [String new become: String new ]]. 684 898 663 812 665 Also, there is a #oneWayBecome: which DOES an object table scan, and makes all references to the receiver point to the argument object (it is, a becomes b, and not the other way around). This gets slow directly proportional to the size of the OT. Time microsecondsToRun: [1000 timesRepeat: [String new become: String new ]]. 10936532 Most proxies and stubs implementations in Dolphin uses #become: because it is instantaneous, and the "old" object (b in this) eventually gets garbage collected. Regards. Esteban A. Maringolo
Re: [Pharo-users] Dynamic example for spec
No one has replied to this post, so I thought I would add my two cents of wit. Many thanks for the example - any addition to the Spec documentation is really useful and I've certainly learned some stuff from your code. But I think if you are aiming to help people learn Spec, then you should add as many comments to the code as you can. Also, allowing the user to edit existing list entries would make the example much more complete. Beyond that, i have to say that the example just confirms my decision not to use Spec at all - at least in its present state. Though this is supposed to be a /dynamic /Spec example, it's really not that dynamic, is it?. You are creating separate instances of a data entry screen here and each separate instance has its own layout - but a truly dynamic Spec example would be one which dynamically/ changed an existing instance/. But this cannot be done currently in Spec as there is no way to change the size of the Spec window once it is created (Bug 13059). It is this limitation I believe that has made you take the separate instances route using a class method. The code for this just seems unnatural to me: DOPartyEditor>>on: aPartyClass ^self basicNew partyClass: aPartyClass; initialize; yourself A more natural approach would be to construct the instance as normal with /DOPartyEditor>>new/ and then set the party class. Changing the party class could then trigger the layout change, allowing the instance to rebuild itself. But this is impossible because of the window resizing issue. I think this is a clear case of Spec's limitations having a detrimental effect on code quality. One thing I had not considered before seeing your code was the consequence of Spec's decision to call its widgets /models/. This causes (at least in my mind) a confusion between the ideas of a model as a problem domain object and a Spec widget. So, in your example, you have a /PartiesModel/ class. So I have to look to see if this inherits from Object or Composable Model because we now have two different ideas of model in the application. So in your code you have: DOPartyEditor>initializeWidgets |models| models := OrderedCollection new. when I read this I was thinking about models as in MVC, not as in ComposableModel. To my mind these lines would be better written as: DOPartyEditor>initializeWidgets |inputWidgets| inputWidgets := OrderedCollection new. Finally, we have the finished product - which I would not show to anyone as an example of a Pharo user interface. You know as well as I do that as soon as the user types in anything they will immediately hit bug 13013 - the font size is far too small and cannot be changed. Can you imagine in what a Java or C# developer would think of this: /Good God these guys are so lame they can't implement the most basic component of a data entry interface - a text entry field. No wonder they can't get Pharo to open up two windows! And yet they claim they have a better way of programming. What are they smoking!./ Who knows what they would think if they knew that an even simpler user interface component - the label - was buggy as well. A /LabelModel /really only has two properties: /label /and /emphasis /and one of them doesn't work! I really think some of this needs to be sorted out before Pharo 3 is released, otherwise the problems with Spec are going to give a very bad impression to any developers who take a look at Pharo hoping to find something better than Java or C#. A possible public relations disaster? -- View this message in context: http://forum.world.st/Dynamic-example-for-spec-tp4756370p4756683.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Dynamic example for spec
Hi kmo, Thanks for your detailed response. You seem to have run into a number of issues I haven’t seen yet while learning spec. I’ll take a look at resizing windows and see how to fix the issue. I have noticed the font size issue and assumed it is to be fixed real soon now. I’ll extend the example to include editing of existing instances. It was suggested that it would be good to have other examples, so I decided to try building a more business-application related one. I am used to dealing with domain models, and will revisit the names. Stephan
Re: [Pharo-users] Dynamic example for spec
/It was suggested that it would be good to have other examples, so I decided to try building a more business-application related one. / Stephan - That's exactly what is needed. It's pet peeve of mine that so many of the Spec examples tend to be browsers. If Pharo wants to position itself as a general purpose application development tool then it has to demonstrate that it can create basic data entry commercial applications. Otherwise we might as well tell business developers to forget about Spec and Morphic and just use Seaside. Ken -- View this message in context: http://forum.world.st/Dynamic-example-for-spec-tp4756370p4756696.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Dynamic example for spec
(responses inline) On Apr 27, 2014, at 10:17 AM, kmo wrote: > No one has replied to this post, so I thought I would add my two cents of > wit. Sadly, I did not have time to study the example because I’m traveling. There are some items in this mail that however I would like to quickly respond to. (Hopefully I will have network along the way somewhere.) > Beyond that, i have to say that the example just confirms my decision not to > use Spec at all - at least in its present state. From your comments below it is not 100% clear to me why you choose not to use Spec at all. Sure, there are some features that are missing. Are these showstoppers for you, and if so, why? Please list and explain. > Though this is supposed to be a /dynamic /Spec example, it's really not that > dynamic, is it?. You are creating separate instances of a data entry screen > here and each separate instance has its own layout - but a truly dynamic > Spec example would be one which dynamically/ changed an existing instance/. > But this cannot be done currently in Spec as there is no way to change the > size of the Spec window once it is created (Bug 13059). I do not agree with your generalization. Still it is possible to add and remove widgets on the fly, as we present in section 5.1 of the Spec chapter in the Pharo For The Enterprise book, […] > One thing I had not considered before seeing your code was the consequence > of Spec's decision to call its widgets /models/. This causes (at least in my > mind) a confusion between the ideas of a model as a problem domain object > and a Spec widget. As we say in the documentation in the book: a widget is something you see on the screen with all its associated state and behavior. But with Spec you don’t code the stuff you see on the screen, you just think about it’s state and behavior, i.e. the model *of the user interface*. > So, in your example, you have a /PartiesModel/ class. So > I have to look to see if this inherits from Object or Composable Model > because we now have two different ideas of model in the application. > > So in your code you have: > > DOPartyEditor>initializeWidgets >|models| >models := OrderedCollection new. > > when I read this I was thinking about models as in MVC, not as in > ComposableModel. To my mind these lines would be better written as: > > DOPartyEditor>initializeWidgets >|inputWidgets| >inputWidgets := OrderedCollection new. Or instead call them uiModels. > Finally, we have the finished product - which I would not show to anyone as > an example of a Pharo user interface. You know as well as I do that as soon > as the user types in anything they will immediately hit bug 13013 - the font > size is far too small and cannot be changed. Can you imagine in what a Java > or C# developer would think of this: /Good God these guys are so lame they > can't implement the most basic component of a data entry interface - a text > entry field. No wonder they can't get Pharo to open up two windows! And yet > they claim they have a better way of programming. What are they smoking!./ There is only so much that a group of, essentially volunteer, developers can do. Comparing it to the multi-million dollar investment that Sun/Oracle/Microsoft/ … have performed is in getting their infrastructure right, inevitably will find issues. The question is: are they showstoppers? What can we do, given our situation? > Who knows what they would think if they knew that an even simpler user > interface component - the label - was buggy as well. A /LabelModel /really > only has two properties: /label /and /emphasis /and one of them doesn't > work! Can you clarify the problem? Is there a bugreport? (I’m without network ATM, otherwise I’d check). > I really think some of this needs to be sorted out before Pharo 3 is > released, otherwise the problems with Spec are going to give a very bad > impression to any developers who take a look at Pharo hoping to find > something better than Java or C#. A possible public relations disaster? I think you are exaggerating. Spec is already an improvement on the UI builders that precede it, and no PR disasters have happened because of these previous frameworks. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
