Re: [Pharo-dev] On Twitter
On Sun, Jan 4, 2015 at 11:08 PM, horrido horrido.hobb...@gmail.com wrote: Thank you for your input. It is very helpful. You're right, retweets can be important, too. I need to put in more effort to draw in more followers. Alas, I don't know where I'm going to find the time. I'm so busy managing all the other stuff (eg, Facebook, Google+, LinkedIn, Amber tutorial, etc.) that I'm starting to get overwhelmed. *This is hard work!* You've leaped in with great enthusiasm and spread yourself too thin? Sounds all too common. Better to do a few things well, so you can enjoy doing it. Half doing something is not so much fun. Don't let yourself get overwhelmed with too high expectations. Building takes time. Keep chipping away at small goals, and make sure you have fun. Like I said in the OP, I'm new to this Twitter thing and I really didn't know how to use it. Maybe you need to drop something, and/or soak up using Twitter in a non-Smalltalk way to get it.Actually I've never used it myself. I must be getting old :) cheers -ben
Re: [Pharo-dev] WhatsUp from: 2015-01-05 until: 2015-01-18
### Here's what I've been up to since the last WhatsUp Released a production version of the network software I've been working on. Got it installed on client premises and it works nicely (very solid server I have to say). Wrote a documentation book using Pillar for the system (worked well after a couple friction moments). Interviewed Herby on Amber Smalltalk Started a book on Amber using Pillar Tweeted some things with the #Pharo hashtag ### What's next, until 2015-01-18 (*): More interviews on Amber (whoever wants one done with Pharo people, just send me a note, I'd be happy to oblige). Prepare talk for FOSDEM Work on Amber Learn more on how to hook databases in Pharo Enter maintenance phase for commercial project before new features developed / support deployments. Phil
Re: [Pharo-dev] WhatsUp from: 2015-01-05 until: 2015-01-18
Le 5/1/15 07:00, seas...@rmod.lille.inria.fr a écrit : Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS Working on updatedPharoByExample ### What's next, until 2015-01-18 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION Working on updatedPharoByExample Preparing PharoDays 2015 (*) we'll be expecting results by then ;)
Re: [Pharo-dev] The Smalltalk Renaissance Program
It depends what is the level you are looking for. We are working on lectures and books for second and third year university students. Now for kids I do not think that it matters if this the language or software is writting in Smalltalk. Stef Le 4/1/15 23:25, horrido a écrit : I am intrigued. Where can I find more info about Smalltalk education in the schools? I want to see what I can do in Canada. I presume there is a Smalltalk image customized for the classroom and aimed at elementary school students. That's what I'm hoping for. stepharo wrote ESUG is about the community. Without community then it is terrible. We set up also a program for teachers. Now in the US there is nearly nobody teaching smalltalk and this is a pity. -- View this message in context: http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797760.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] CubeHelix integration (issue 14648 in update #40423)
What is the reasons for integration of class CubeHelix into standard Pharo image: https://pharo.fogbugz.com/f/cases/14648 So far the class is not (yet) referenced. This is normal Would'nt it make sense to have Chroma-CubeHelix as external loadable package? No! The color and core graphics should improve. Out of the box we should have much better color algorithms. For example decent palettes should follow. If you are looking for extra classes I'm sure that you can find some better candidates. Thanks for any clarification! Bye T.
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
You summarise well the kind of code I do not like. isNil everywhere and horrible tests. Stef Le 4/1/15 23:27, Sebastian Sastre a écrit : Hi guys, I’ve started to use this little one: ObjectifNilOrEmpty: aBlock self ifNil: [ ^ aBlock value ]. (self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ]. ^ self. It allows you to do the widely known JavaScript one-liner: var stuff = this.thing || ‘some default value for when this.thing is undefined, null or an empty string’. but in smalltalk in this way: stuff := self thing ifNilOrEmpty: [ ‘some default value for when self thing is nil or an empty string’ ] simple thing feels practical and nice :)
Re: [Pharo-dev] WhatsUp from: 2015-01-05 until: 2015-01-18
### Here's what I've been up to since the last WhatsUp - Finished the release of Moose 5.0 - Continued documenting GTInspector scenarios: http://www.humane-assessment.com/blog/identifying-a-configuration-problem-with-gtinspector ### What's next, until 2015-01-18 (*): - Continue with new cool GT things -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
taste is taste but would you care to illustrate your point with examples? I’m curious about it On Jan 5, 2015, at 6:12 AM, stepharo steph...@free.fr wrote: You summarise well the kind of code I do not like. isNil everywhere and horrible tests. Stef Le 4/1/15 23:27, Sebastian Sastre a écrit : Hi guys, I’ve started to use this little one: ObjectifNilOrEmpty: aBlock self ifNil: [ ^ aBlock value ]. (self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ]. ^ self. It allows you to do the widely known JavaScript one-liner: var stuff = this.thing || ‘some default value for when this.thing is undefined, null or an empty string’. but in smalltalk in this way: stuff := self thing ifNilOrEmpty: [ ‘some default value for when self thing is nil or an empty string’ ] simple thing feels practical and nice :)
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection. A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty. Cheers, Doru On Mon, Jan 5, 2015 at 1:17 PM, Sebastian Sastre sebast...@flowingconcept.com wrote: taste is taste but would you care to illustrate your point with examples? I’m curious about it On Jan 5, 2015, at 6:12 AM, stepharo steph...@free.fr wrote: You summarise well the kind of code I do not like. isNil everywhere and horrible tests. Stef Le 4/1/15 23:27, Sebastian Sastre a écrit : Hi guys, I’ve started to use this little one: ObjectifNilOrEmpty: aBlock self ifNil: [ ^ aBlock value ]. (self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ]. ^ self. It allows you to do the widely known JavaScript one-liner: var stuff = this.thing || ‘some default value for when this.thing is undefined, null or an empty string’. but in smalltalk in this way: stuff := self thing ifNilOrEmpty: [ ‘some default value for when self thing is nil or an empty string’ ] simple thing feels practical and nice :) -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40429 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] [pharo-project/pharo-core] a28e71: 40429
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: a28e7177916f5db79ce3ca9b60d4bc0f5e7cad9c https://github.com/pharo-project/pharo-core/commit/a28e7177916f5db79ce3ca9b60d4bc0f5e7cad9c Author: Jenkins Build Server bo...@pharo-project.org Date: 2015-01-05 (Mon, 05 Jan 2015) Changed paths: M Kernel.package/Float.class/class/instance creation/fromIEEE32Bit_.st A KernelTests.package/FloatTest.class/instance/tests - IEEE 754/test32bitConversion.st A Morphic-Core.package/HandMorph.class/class/events-processing/cleanUp.st A Morphic-Core.package/HandMorph.class/class/events-processing/eventStats.st A Morphic-Core.package/HandMorph.class/class/events-processing/logEventStatsStart.st A Morphic-Core.package/HandMorph.class/class/events-processing/logEventStatsStop.st A Morphic-Core.package/HandMorph.class/class/events-processing/logEventStats_.st A Morphic-Core.package/HandMorph.class/class/settings/logEventStatsEnabled.st A Morphic-Core.package/HandMorph.class/class/settings/logEventStatsEnabled_.st A Morphic-Core.package/HandMorph.class/class/settings/settingsOn_.st M Morphic-Core.package/HandMorph.class/instance/events-processing/handleEvent_.st R Morphic-Core.package/HandMorph.class/instance/events-processing/logEventStats_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script429.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40429.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: --- 40429 14668 HandMorph event statistics should be off by default with preference https://pharo.fogbugz.com/f/cases/14668 14652 Float class fromIEEE32Bit: gradual underflow handling is buggy https://pharo.fogbugz.com/f/cases/14652 http://files.pharo.org/image/40/40429.zip
Re: [Pharo-dev] Old inspector and explorer
+1 Remember that “old” also means that it stands the test of time We need to be careful while innovating with the basics (workspace, inspecting, navigating code and debugging) because that impacts the whole economy of using this technology. Make productivity go up, never down! One additional click doesn’t sound like a lot but if that happens for something that you do 400 times a day is ~8000 times a month or ~60 minutes of clicking like crazy with overhead you didn’t have before. UX is King. No way back from that, it really rules (the only thing we have in control is what kingdom will we invent for it to rule) On Dec 26, 2014, at 2:42 PM, stepharo steph...@free.fr wrote: + 1 Debugging the rendering loops of Athens was such an example. In Bloc I get some race conditions with MC forked process... another fun one. Let people decide!!! Doru I DO NOT WANT TO LEARN WHAT I DO NOT WANT TO LEARN! I WANT to DECIDE WHEN. I control my agenda and my own schedule and my list is huge. Stef Doru, I think your intention is a good one but slightly misplaced. I really like the idea of GTInspector. It surely is a great tool and maybe I'll start to build my own inspector on my kind of things. To me the difference is between motivated to do or forced to do. Most of the time we are trying hard to solve our own problems. If in that progress other problems are forced upon us we get easily distracted and frustrated. The same goes for new tools. If I'm forced to use these it just means I have to deal with it first and only then I'm allowed to deal with my own problem. As it was in that special case the bug in nautilus and the new inspector made me shy away from developing something in 4.0 and now I'm back on 3.0. So I think the only possibility is to offer a new way of doing things and give people time to adjust. Norbert Am 26.12.2014 um 13:18 schrieb Tudor Girba tu...@tudorgirba.com mailto:tu...@tudorgirba.com: Hi, I think there must be a misunderstanding. There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use. There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore. What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear? But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger. Cheers, Doru On Thu, Dec 25, 2014 at 11:43 AM, stepharo steph...@free.fr mailto:steph...@free.fr wrote: I will add basicInspect in Object so that we can get access to the old inspector. I like that people can choose their tools! I mentioned that 20 times but people do not care apparently. Stef Le 23/12/14 11:50, Norbert Hartl a écrit : Is there a way to get the old tools via shortcut? I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I just want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools. Norbert -- www.tudorgirba.com http://www.tudorgirba.com/ Every thing has its own flow
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
Am 05.01.2015 um 14:43 schrieb Sebastian Sastre sebast...@flowingconcept.com: one hugely typical case is having the model of an input that has either nil because is pristine or an empty string and the app needs to guarantee some default value that should not be nil or an empty string. Another frequent case is the response of some API that will typically answer nil or an empty collection when something is not found and you want to guarantee some value or model that should not be nil or an empty collection. About #thing being meaningless, sure, I’ve mentioned as general example. I don’t see that every user of #thing has to use the ifNilOrEmpty:, only those who care about guaranteeing that closure valued if none is found which is expressed in the completely sensible form of receiving nil or an empty collection :) My point is that as long as you do not promise a certain type of object you will have to deal with the uncertainty what methods you can call on that object of uncertain type. By not using a check you just extend the life of this uncertainty a while longer (bad if the user of your code has to deal with it). Some has to deal with it if the object has to do something. And the earlier this uncertainty is removed the better it is. At least in my opinion. Norbert Thanks for giving it a thought On Jan 5, 2015, at 11:14 AM, Norbert Hartl norb...@hartl.name mailto:norb...@hartl.name wrote: Am 05.01.2015 um 14:01 schrieb Sebastian Sastre sebast...@flowingconcept.com mailto:sebast...@flowingconcept.com: On Jan 5, 2015, at 10:38 AM, p...@highoctane.be mailto:p...@highoctane.be wrote: In business apps, the need for default values happen all the time, so the idiom has value (not sure for the message name though). Totally. In real apps, having to compare against uninitialized variable or nil as response or empty string happens so often that having this method makes it quite convenient (AKA lots of code becomes one-liners). We could use x := [ self thing ] ifError: [ someDefault ] I understand you’re setting a similar, quite not like it example but in any case this one raises and catches an exception and that sounds quite less efficient if compared to return self (when object is not nil and is not an empty collection/string) for these purposes. Triggering errors is not too nice still. Now, what if self itself is nil or empty? BTW, isEmptyOrNil exists in the image for Collections and UndefinedObject. Empty has no meaning for Object, so why test against empty in the name? Note that is not a testing method, it’s a conditional executor of the closure. The reason why was already mentioned, is to allow you to write this one-liner convenience: someVar := self thing ifNilOrEmpty: [blah] `self thing` could be an expensive process that returns something or nil or an empty collection. If you get nil or empty as result then you would get the block values resulting in having blah at someVar In the image, I see that we do have #default: anObject in several places. It seems to serve the same intent. What is the idiom for such things in Pharo? Importing idioms from other languages works but if we do have one already, we will introduce confusion. how can you do that one-liner without introducing ifNilOrEmpty: ? What is #thing supposed to do? This whole problem looks like a typical javascript problem. You do anything and return anything and as all types are auto-coerced into their target type all expressions look like the same while meaning different things. It looks problematic to me to treat nil and empty collection the same. This might make sense in some business logic but not in general. In that move a method is added to Object using methods it cannot know of like #isEmpty. Object is no way more tied to Collection than it should be. Another problem is that #thing does return anything but nothing meaningful. So every user of #thing has to use the #ifNilOrEmpty: foo. This is probably something that needs to go into the class the implements #thing. Everything else is far from being an interface. Probably the solution to this is that #thing should return a concrete type object that can be used with its defined interface. So if having an one-liner is the ultimate goal one might need see the harm it produced on the way. my 2 cents, norbert Phil On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba tu...@tudorgirba.com mailto:tu...@tudorgirba.com wrote: This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection. A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty. Cheers, Doru On Mon, Jan 5, 2015 at 1:17 PM, Sebastian Sastre sebast...@flowingconcept.com mailto:sebast...@flowingconcept.com wrote: taste is taste but
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
El Mon Jan 05 2015 at 10:50:48 AM, p...@highoctane.be p...@highoctane.be escribió: Why not put that into a Trait? TDefaultValueIdiomifEmptyOrNil: aDefaultObject So, if wanted,, one can put uses TDefaultValueIdiom (I am at a loss for a great name here, help!) and do as Sebastian proposes. This will prevent pollution of Object while at the same time being able to have the idiom available (and maybe with more than one form). But you can't hot plug a Trait to Object to have this behavior system-wide. Adding a trait involves recompilation AFAIR. The only thing I'd argue against is the naming. Otherwise is a very convenient method, when you go outside of the Smalltalk island and interact with API's not very well crafted or desgned to err on the safe side (empty collections instead o null), asking whether an object isNull or empty in the same method is really convenient. If we get purists, nil shouldn't exist either [1] and they should be replaced by domain specific abstractions representing the void/undefined. But we know there is a use case for nil, as IMO, there is a use case for isEmptyOrNil. However, whether you add it to Object in Pharo core image or not isn't really relevant, whoever wants/needs it can add it afterwards. Regards, [1] http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare
Re: [Pharo-dev] Old inspector and explorer
Hi Sebastian, I really do not see how your reply applies to the case at hand. If you have a concrete remark regarding how something is less useful now, please feel free to make it. Cheers, Doru On Mon, Jan 5, 2015 at 3:00 PM, Sebastian Sastre sebast...@flowingconcept.com wrote: +1 Remember that “old” also means that it *stands the test of time* We need to be careful while innovating with the basics (workspace, inspecting, navigating code and debugging) because that impacts the whole economy of using this technology. Make productivity go up, never down! One additional click doesn’t sound like a lot but if that happens for something that you do 400 times a day is ~8000 times a month or ~60 minutes of clicking like crazy with overhead you didn’t have before. UX is King. No way back from that, it really rules (the only thing we have in control is what kingdom will we invent for it to rule) On Dec 26, 2014, at 2:42 PM, stepharo steph...@free.fr wrote: + 1 Debugging the rendering loops of Athens was such an example. In Bloc I get some race conditions with MC forked process... another fun one. Let people decide!!! Doru I DO NOT WANT TO LEARN WHAT I DO NOT WANT TO LEARN! I WANT to DECIDE WHEN. I control my agenda and my own schedule and my list is huge. Stef Doru, I think your intention is a good one but slightly misplaced. I really like the idea of GTInspector. It surely is a great tool and maybe I'll start to build my own inspector on my kind of things. To me the difference is between motivated to do or forced to do. Most of the time we are trying hard to solve our own problems. If in that progress other problems are forced upon us we get easily distracted and frustrated. The same goes for new tools. If I'm forced to use these it just means I have to deal with it first and only then I'm allowed to deal with my own problem. As it was in that special case the bug in nautilus and the new inspector made me shy away from developing something in 4.0 and now I'm back on 3.0. So I think the only possibility is to offer a new way of doing things and give people time to adjust. Norbert Am 26.12.2014 um 13:18 schrieb Tudor Girba tu...@tudorgirba.com: Hi, I think there must be a misunderstanding. There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use. There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore. What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear? But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger. Cheers, Doru On Thu, Dec 25, 2014 at 11:43 AM, stepharo steph...@free.fr wrote: I will add basicInspect in Object so that we can get access to the old inspector. I like that people can choose their tools! I mentioned that 20 times but people do not care apparently. Stef Le 23/12/14 11:50, Norbert Hartl a écrit : Is there a way to get the old tools via shortcut? I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I just want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools. Norbert -- www.tudorgirba.com Every thing has its own flow --
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
On 05 Jan 2015, at 12:06 , Sebastian Sastre sebast...@flowingconcept.com wrote: but not putting it on Object would change the feature since you do want it returning self on that case. No. In that case, you want to use ifNil: , not ifNilOrEmpty:. The only thing Object ifNilOrEmpty would support, is putting both collections and non-collection in the same variable, which is usually a bad idea to begin with, since it will lead to are you a collection or single instance? checks in almost every user of said variable. Cheers, Henry
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
On Jan 5, 2015, at 12:00 PM, Norbert Hartl norb...@hartl.name wrote: Am 05.01.2015 um 14:43 schrieb Sebastian Sastre sebast...@flowingconcept.com mailto:sebast...@flowingconcept.com: one hugely typical case is having the model of an input that has either nil because is pristine or an empty string and the app needs to guarantee some default value that should not be nil or an empty string. Another frequent case is the response of some API that will typically answer nil or an empty collection when something is not found and you want to guarantee some value or model that should not be nil or an empty collection. About #thing being meaningless, sure, I’ve mentioned as general example. I don’t see that every user of #thing has to use the ifNilOrEmpty:, only those who care about guaranteeing that closure valued if none is found which is expressed in the completely sensible form of receiving nil or an empty collection :) My point is that as long as you do not promise a certain type of object you will have to deal with the uncertainty what methods you can call on that object of uncertain type. By not using a check you just extend the life of this uncertainty a while longer (bad if the user of your code has to deal with it). Some has to deal with it if the object has to do something. And the earlier this uncertainty is removed the better it is. At least in my opinion. Norbert Ah! I understand your point better now, thanks for clarifying. Actually you helped me to understand better something I systematically do often which is extending that uncertainty as much as is convenient :) For example Mapless http://sebastianconcept.github.io/Mapless (and MiniMapless https://github.com/flow-stack/MiniMapless) gives you the freedom of not having to predict what instance variables your persistent objects will have and still gives you the features now. Is the opposite of the predictive certainty demanded by typed technologies and their the compiler is your friend BS that completely frustrates your creative flow. Dynamic technologies are all about delaying certainty. Late binding is delaying it until runtime. I don’t say this as a technicality, I see it as a useful tool to push the present into the future and pull the future into the present. Being able to reflect in real-time makes this possible. Is what makes easier to invent the future when they “touch each other. If someone else has to deal with the object and code with this uncertainty, you know you’re on the right place for personal mastery http://www.cs.virginia.edu/~cs655/readings/smalltalk.html to happen since Smalltalk was designed to allow the individual to easily navigate code and master the system by itself. This is actually a major reason to choose Smalltalk. Thanks again!
Re: [Pharo-dev] [Bulk] [Bulk] Can MongoTalk execute plan javascript MongoDB queries?
Am 05.01.2015 um 04:59 schrieb Yanni Chiu ya...@rogers.com:
On Jan 4, 2015, at 4:38 AM, Norbert Hartl norb...@hartl.name wrote:
someCollection select: {
'$or' - {
{ 'name' - {
'$regex' - 'test' .
'$options' - 'i' } asDictionary } asDictionary.
{ 'description' - {
'$regex' - 'test' .
'$options' - 'i' } asDictionary } asDictionary
}
} asDictionary
That worked. I was close, but I was using $or: instead of $or, and I was
missing one level of asDictionary.
Just for the archive, there’s one more query I needed, which was to find an
object based on it’s object id. I ended up using:
voyageId := Integer readFrom: (request at: #voyageId) base: 16.
someModel := SomeModel selectOne: { '_id' - (OID value: voyageId) }
asDictionary.
This is a web app using Teapot and Mustache, so I write the voyageId out
using:
self voyageId value printStringHex
Sounds cool. If you have anything to publish I'm interested what you've done.
Especially if you have some nice tricks doing form handling in teapot.
Btw. for the archive. A common use case I encounter is to query objects that
are being referenced by another object. It works like this
AnyClass#referencedBy: anObject
^ AnyClass selectMany: {
'reference.__id' - anObject voyageId } asDictionary
Norbert
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
On Jan 5, 2015, at 10:38 AM, p...@highoctane.be wrote: In business apps, the need for default values happen all the time, so the idiom has value (not sure for the message name though). Totally. In real apps, having to compare against uninitialized variable or nil as response or empty string happens so often that having this method makes it quite convenient (AKA lots of code becomes one-liners). We could use x := [ self thing ] ifError: [ someDefault ] I understand you’re setting a similar, quite not like it example but in any case this one raises and catches an exception and that sounds quite less efficient if compared to return self (when object is not nil and is not an empty collection/string) for these purposes. Triggering errors is not too nice still. Now, what if self itself is nil or empty? BTW, isEmptyOrNil exists in the image for Collections and UndefinedObject. Empty has no meaning for Object, so why test against empty in the name? Note that is not a testing method, it’s a conditional executor of the closure. The reason why was already mentioned, is to allow you to write this one-liner convenience: someVar := self thing ifNilOrEmpty: [blah] `self thing` could be an expensive process that returns something or nil or an empty collection. If you get nil or empty as result then you would get the block values resulting in having blah at someVar In the image, I see that we do have #default: anObject in several places. It seems to serve the same intent. What is the idiom for such things in Pharo? Importing idioms from other languages works but if we do have one already, we will introduce confusion. how can you do that one-liner without introducing ifNilOrEmpty: ? Phil On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba tu...@tudorgirba.com mailto:tu...@tudorgirba.com wrote: This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection. A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty. Cheers, Doru On Mon, Jan 5, 2015 at 1:17 PM, Sebastian Sastre sebast...@flowingconcept.com mailto:sebast...@flowingconcept.com wrote: taste is taste but would you care to illustrate your point with examples? I’m curious about it On Jan 5, 2015, at 6:12 AM, stepharo steph...@free.fr mailto:steph...@free.fr wrote: You summarise well the kind of code I do not like. isNil everywhere and horrible tests. Stef Le 4/1/15 23:27, Sebastian Sastre a écrit : Hi guys, I’ve started to use this little one: ObjectifNilOrEmpty: aBlock self ifNil: [ ^ aBlock value ]. (self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ]. ^ self. It allows you to do the widely known JavaScript one-liner: var stuff = this.thing || ‘some default value for when this.thing is undefined, null or an empty string’. but in smalltalk in this way: stuff := self thing ifNilOrEmpty: [ ‘some default value for when self thing is nil or an empty string’ ] simple thing feels practical and nice :) -- www.tudorgirba.com http://www.tudorgirba.com/ Every thing has its own flow -- --- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be mailto:mail%3ap...@highoctane.be | Web: http://philippeback.eu http://philippeback.eu/ Blog: http://philippeback.be http://philippeback.be/ | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com http://spamcast.libsyn.com/ Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
Am 05.01.2015 um 14:01 schrieb Sebastian Sastre sebast...@flowingconcept.com: On Jan 5, 2015, at 10:38 AM, p...@highoctane.be mailto:p...@highoctane.be wrote: In business apps, the need for default values happen all the time, so the idiom has value (not sure for the message name though). Totally. In real apps, having to compare against uninitialized variable or nil as response or empty string happens so often that having this method makes it quite convenient (AKA lots of code becomes one-liners). We could use x := [ self thing ] ifError: [ someDefault ] I understand you’re setting a similar, quite not like it example but in any case this one raises and catches an exception and that sounds quite less efficient if compared to return self (when object is not nil and is not an empty collection/string) for these purposes. Triggering errors is not too nice still. Now, what if self itself is nil or empty? BTW, isEmptyOrNil exists in the image for Collections and UndefinedObject. Empty has no meaning for Object, so why test against empty in the name? Note that is not a testing method, it’s a conditional executor of the closure. The reason why was already mentioned, is to allow you to write this one-liner convenience: someVar := self thing ifNilOrEmpty: [blah] `self thing` could be an expensive process that returns something or nil or an empty collection. If you get nil or empty as result then you would get the block values resulting in having blah at someVar In the image, I see that we do have #default: anObject in several places. It seems to serve the same intent. What is the idiom for such things in Pharo? Importing idioms from other languages works but if we do have one already, we will introduce confusion. how can you do that one-liner without introducing ifNilOrEmpty: ? What is #thing supposed to do? This whole problem looks like a typical javascript problem. You do anything and return anything and as all types are auto-coerced into their target type all expressions look like the same while meaning different things. It looks problematic to me to treat nil and empty collection the same. This might make sense in some business logic but not in general. In that move a method is added to Object using methods it cannot know of like #isEmpty. Object is no way more tied to Collection than it should be. Another problem is that #thing does return anything but nothing meaningful. So every user of #thing has to use the #ifNilOrEmpty: foo. This is probably something that needs to go into the class the implements #thing. Everything else is far from being an interface. Probably the solution to this is that #thing should return a concrete type object that can be used with its defined interface. So if having an one-liner is the ultimate goal one might need see the harm it produced on the way. my 2 cents, norbert Phil On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba tu...@tudorgirba.com mailto:tu...@tudorgirba.com wrote: This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection. A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty. Cheers, Doru On Mon, Jan 5, 2015 at 1:17 PM, Sebastian Sastre sebast...@flowingconcept.com mailto:sebast...@flowingconcept.com wrote: taste is taste but would you care to illustrate your point with examples? I’m curious about it On Jan 5, 2015, at 6:12 AM, stepharo steph...@free.fr mailto:steph...@free.fr wrote: You summarise well the kind of code I do not like. isNil everywhere and horrible tests. Stef Le 4/1/15 23:27, Sebastian Sastre a écrit : Hi guys, I’ve started to use this little one: ObjectifNilOrEmpty: aBlock self ifNil: [ ^ aBlock value ]. (self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ]. ^ self. It allows you to do the widely known JavaScript one-liner: var stuff = this.thing || ‘some default value for when this.thing is undefined, null or an empty string’. but in smalltalk in this way: stuff := self thing ifNilOrEmpty: [ ‘some default value for when self thing is nil or an empty string’ ] simple thing feels practical and nice :) -- www.tudorgirba.com http://www.tudorgirba.com/ Every thing has its own flow -- --- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be mailto:mail%3ap...@highoctane.be | Web: http://philippeback.eu http://philippeback.eu/ Blog: http://philippeback.be http://philippeback.be/ | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
Exception handling is used a lot. Check senders of #on:do: 457 in my Pharo 3.0 That's not counting the 303 #ensure: that are used transparently in things like: aFileRef readStreamDo: [ :s | s upToEnd ] Phil On Mon, Jan 5, 2015 at 2:12 PM, kilon alios kilon.al...@gmail.com wrote: I dont know javascript well nor pharo but I am coming from python and for this scenario it would make more sense to me to use an exception than an actual check. At least that is the way Python deals with this situation which is an approach I really like. I know Pharo has exception handling as well, but unlike Python where exception handling is very popular I have barely seen it used by pharo coders. I am curious why . On Mon, Jan 5, 2015 at 3:01 PM, Sebastian Sastre sebast...@flowingconcept.com wrote: On Jan 5, 2015, at 10:38 AM, p...@highoctane.be wrote: In business apps, the need for default values happen all the time, so the idiom has value (not sure for the message name though). Totally. In real apps, having to compare against uninitialized variable or nil as response or empty string happens so often that having this method makes it quite convenient (AKA lots of code becomes one-liners). We could use x := [ self thing ] ifError: [ someDefault ] I understand you’re setting a similar, quite not like it example but in any case this one raises and catches an exception and that sounds quite less efficient if compared to return self (when object is not nil and is not an empty collection/string) for these purposes. Triggering errors is not too nice still. Now, what if self itself is nil or empty? BTW, isEmptyOrNil exists in the image for Collections and UndefinedObject. Empty has no meaning for Object, so why test against empty in the name? Note that is not a testing method, it’s a conditional executor of the closure. The reason why was already mentioned, is to allow you to write this one-liner convenience: someVar := self thing ifNilOrEmpty: [blah] `self thing` could be an expensive process that returns something or nil or an empty collection. *If* you get nil or empty as result then you would get the block values resulting in having blah at someVar In the image, I see that we do have #default: anObject in several places. It seems to serve the same intent. What is the idiom for such things in Pharo? Importing idioms from other languages works but if we do have one already, we will introduce confusion. how can you do that one-liner without introducing *ifNilOrEmpty:* ? Phil On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba tu...@tudorgirba.com wrote: This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection. A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty. Cheers, Doru On Mon, Jan 5, 2015 at 1:17 PM, Sebastian Sastre sebast...@flowingconcept.com wrote: taste is taste but would you care to illustrate your point with examples? I’m curious about it On Jan 5, 2015, at 6:12 AM, stepharo steph...@free.fr wrote: You summarise well the kind of code I do not like. isNil everywhere and horrible tests. Stef Le 4/1/15 23:27, Sebastian Sastre a écrit : Hi guys, I’ve started to use this little one: ObjectifNilOrEmpty: aBlock self ifNil: [ ^ aBlock value ]. (self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ]. ^ self. It allows you to do the widely known JavaScript one-liner: var stuff = this.thing || ‘some default value for when this.thing is undefined, null or an empty string’. but in smalltalk in this way: stuff := self thing ifNilOrEmpty: [ ‘some default value for when self thing is nil or an empty string’ ] simple thing feels practical and nice :) -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
one hugely typical case is having the model of an input that has either nil because is pristine or an empty string and the app needs to guarantee some default value that should not be nil or an empty string. Another frequent case is the response of some API that will typically answer nil or an empty collection when something is not found and you want to guarantee some value or model that should not be nil or an empty collection. About #thing being meaningless, sure, I’ve mentioned as general example. I don’t see that every user of #thing has to use the ifNilOrEmpty:, only those who care about guaranteeing that closure valued if none is found which is expressed in the completely sensible form of receiving nil or an empty collection :) Thanks for giving it a thought On Jan 5, 2015, at 11:14 AM, Norbert Hartl norb...@hartl.name wrote: Am 05.01.2015 um 14:01 schrieb Sebastian Sastre sebast...@flowingconcept.com mailto:sebast...@flowingconcept.com: On Jan 5, 2015, at 10:38 AM, p...@highoctane.be mailto:p...@highoctane.be wrote: In business apps, the need for default values happen all the time, so the idiom has value (not sure for the message name though). Totally. In real apps, having to compare against uninitialized variable or nil as response or empty string happens so often that having this method makes it quite convenient (AKA lots of code becomes one-liners). We could use x := [ self thing ] ifError: [ someDefault ] I understand you’re setting a similar, quite not like it example but in any case this one raises and catches an exception and that sounds quite less efficient if compared to return self (when object is not nil and is not an empty collection/string) for these purposes. Triggering errors is not too nice still. Now, what if self itself is nil or empty? BTW, isEmptyOrNil exists in the image for Collections and UndefinedObject. Empty has no meaning for Object, so why test against empty in the name? Note that is not a testing method, it’s a conditional executor of the closure. The reason why was already mentioned, is to allow you to write this one-liner convenience: someVar := self thing ifNilOrEmpty: [blah] `self thing` could be an expensive process that returns something or nil or an empty collection. If you get nil or empty as result then you would get the block values resulting in having blah at someVar In the image, I see that we do have #default: anObject in several places. It seems to serve the same intent. What is the idiom for such things in Pharo? Importing idioms from other languages works but if we do have one already, we will introduce confusion. how can you do that one-liner without introducing ifNilOrEmpty: ? What is #thing supposed to do? This whole problem looks like a typical javascript problem. You do anything and return anything and as all types are auto-coerced into their target type all expressions look like the same while meaning different things. It looks problematic to me to treat nil and empty collection the same. This might make sense in some business logic but not in general. In that move a method is added to Object using methods it cannot know of like #isEmpty. Object is no way more tied to Collection than it should be. Another problem is that #thing does return anything but nothing meaningful. So every user of #thing has to use the #ifNilOrEmpty: foo. This is probably something that needs to go into the class the implements #thing. Everything else is far from being an interface. Probably the solution to this is that #thing should return a concrete type object that can be used with its defined interface. So if having an one-liner is the ultimate goal one might need see the harm it produced on the way. my 2 cents, norbert Phil On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba tu...@tudorgirba.com mailto:tu...@tudorgirba.com wrote: This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection. A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty. Cheers, Doru On Mon, Jan 5, 2015 at 1:17 PM, Sebastian Sastre sebast...@flowingconcept.com mailto:sebast...@flowingconcept.com wrote: taste is taste but would you care to illustrate your point with examples? I’m curious about it On Jan 5, 2015, at 6:12 AM, stepharo steph...@free.fr mailto:steph...@free.fr wrote: You summarise well the kind of code I do not like. isNil everywhere and horrible tests. Stef Le 4/1/15 23:27, Sebastian Sastre a écrit : Hi guys, I’ve started to use this little one: ObjectifNilOrEmpty: aBlock self ifNil: [ ^ aBlock value ]. (self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ]. ^ self. It allows you to do the widely known
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
Why not put that into a Trait? TDefaultValueIdiomifEmptyOrNil: aDefaultObject So, if wanted,, one can put uses TDefaultValueIdiom (I am at a loss for a great name here, help!) and do as Sebastian proposes. This will prevent pollution of Object while at the same time being able to have the idiom available (and maybe with more than one form). Phil On Mon, Jan 5, 2015 at 2:43 PM, Sebastian Sastre sebast...@flowingconcept.com wrote: one hugely typical case is having the model of an input that has either nil because is pristine or an empty string and the app needs to guarantee some default value that should *not be nil or an empty string*. Another frequent case is the response of some API that will typically answer nil or an empty collection when something is not found and you want to guarantee some value or model that should *not* be nil or an empty collection. About #thing being meaningless, sure, I’ve mentioned as general example. I don’t see that every user of #thing *has* to use the ifNilOrEmpty:, only those who care about guaranteeing that closure valued *if* none is found which is expressed in the completely sensible form of receiving nil or an empty collection :) Thanks for giving it a thought On Jan 5, 2015, at 11:14 AM, Norbert Hartl norb...@hartl.name wrote: Am 05.01.2015 um 14:01 schrieb Sebastian Sastre sebast...@flowingconcept.com: On Jan 5, 2015, at 10:38 AM, p...@highoctane.be wrote: In business apps, the need for default values happen all the time, so the idiom has value (not sure for the message name though). Totally. In real apps, having to compare against uninitialized variable or nil as response or empty string happens so often that having this method makes it quite convenient (AKA lots of code becomes one-liners). We could use x := [ self thing ] ifError: [ someDefault ] I understand you’re setting a similar, quite not like it example but in any case this one raises and catches an exception and that sounds quite less efficient if compared to return self (when object is not nil and is not an empty collection/string) for these purposes. Triggering errors is not too nice still. Now, what if self itself is nil or empty? BTW, isEmptyOrNil exists in the image for Collections and UndefinedObject. Empty has no meaning for Object, so why test against empty in the name? Note that is not a testing method, it’s a conditional executor of the closure. The reason why was already mentioned, is to allow you to write this one-liner convenience: someVar := self thing ifNilOrEmpty: [blah] `self thing` could be an expensive process that returns something or nil or an empty collection. *If* you get nil or empty as result then you would get the block values resulting in having blah at someVar In the image, I see that we do have #default: anObject in several places. It seems to serve the same intent. What is the idiom for such things in Pharo? Importing idioms from other languages works but if we do have one already, we will introduce confusion. how can you do that one-liner without introducing *ifNilOrEmpty:* ? What is #thing supposed to do? This whole problem looks like a typical javascript problem. You do anything and return anything and as all types are auto-coerced into their target type all expressions look like the same while meaning different things. It looks problematic to me to treat nil and empty collection the same. This might make sense in some business logic but not in general. In that move a method is added to Object using methods it cannot know of like #isEmpty. Object is no way more tied to Collection than it should be. Another problem is that #thing does return anything but nothing meaningful. So every user of #thing has to use the #ifNilOrEmpty: foo. This is probably something that needs to go into the class the implements #thing. Everything else is far from being an interface. Probably the solution to this is that #thing should return a concrete type object that can be used with its defined interface. So if having an one-liner is the ultimate goal one might need see the harm it produced on the way. my 2 cents, norbert Phil On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba tu...@tudorgirba.com wrote: This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection. A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty. Cheers, Doru On Mon, Jan 5, 2015 at 1:17 PM, Sebastian Sastre sebast...@flowingconcept.com wrote: taste is taste but would you care to illustrate your point with examples? I’m curious about it On Jan 5, 2015, at 6:12 AM, stepharo steph...@free.fr wrote: You summarise well the kind of code I do not like. isNil everywhere and horrible tests. Stef Le 4/1/15 23:27, Sebastian Sastre a écrit : Hi guys, I’ve started to use
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
On Jan 5, 2015, at 10:19 AM, Tudor Girba tu...@tudorgirba.com wrote: This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection. A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty. Cheers, Doru ok, why?
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
In business apps, the need for default values happen all the time, so the idiom has value (not sure for the message name though). We could use x := [ self thing ] ifError: [ someDefault ] for these purposes. Triggering errors is not too nice still. Now, what if self itself is nil or empty? BTW, isEmptyOrNil exists in the image for Collections and UndefinedObject. Empty has no meaning for Object, so why test against empty in the name? In the image, I see that we do have #default: anObject in several places. It seems to serve the same intent. What is the idiom for such things in Pharo? Importing idioms from other languages works but if we do have one already, we will introduce confusion. Phil On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba tu...@tudorgirba.com wrote: This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection. A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty. Cheers, Doru On Mon, Jan 5, 2015 at 1:17 PM, Sebastian Sastre sebast...@flowingconcept.com wrote: taste is taste but would you care to illustrate your point with examples? I’m curious about it On Jan 5, 2015, at 6:12 AM, stepharo steph...@free.fr wrote: You summarise well the kind of code I do not like. isNil everywhere and horrible tests. Stef Le 4/1/15 23:27, Sebastian Sastre a écrit : Hi guys, I’ve started to use this little one: ObjectifNilOrEmpty: aBlock self ifNil: [ ^ aBlock value ]. (self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ]. ^ self. It allows you to do the widely known JavaScript one-liner: var stuff = this.thing || ‘some default value for when this.thing is undefined, null or an empty string’. but in smalltalk in this way: stuff := self thing ifNilOrEmpty: [ ‘some default value for when self thing is nil or an empty string’ ] simple thing feels practical and nice :) -- www.tudorgirba.com Every thing has its own flow -- --- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
I dont know javascript well nor pharo but I am coming from python and for this scenario it would make more sense to me to use an exception than an actual check. At least that is the way Python deals with this situation which is an approach I really like. I know Pharo has exception handling as well, but unlike Python where exception handling is very popular I have barely seen it used by pharo coders. I am curious why . On Mon, Jan 5, 2015 at 3:01 PM, Sebastian Sastre sebast...@flowingconcept.com wrote: On Jan 5, 2015, at 10:38 AM, p...@highoctane.be wrote: In business apps, the need for default values happen all the time, so the idiom has value (not sure for the message name though). Totally. In real apps, having to compare against uninitialized variable or nil as response or empty string happens so often that having this method makes it quite convenient (AKA lots of code becomes one-liners). We could use x := [ self thing ] ifError: [ someDefault ] I understand you’re setting a similar, quite not like it example but in any case this one raises and catches an exception and that sounds quite less efficient if compared to return self (when object is not nil and is not an empty collection/string) for these purposes. Triggering errors is not too nice still. Now, what if self itself is nil or empty? BTW, isEmptyOrNil exists in the image for Collections and UndefinedObject. Empty has no meaning for Object, so why test against empty in the name? Note that is not a testing method, it’s a conditional executor of the closure. The reason why was already mentioned, is to allow you to write this one-liner convenience: someVar := self thing ifNilOrEmpty: [blah] `self thing` could be an expensive process that returns something or nil or an empty collection. *If* you get nil or empty as result then you would get the block values resulting in having blah at someVar In the image, I see that we do have #default: anObject in several places. It seems to serve the same intent. What is the idiom for such things in Pharo? Importing idioms from other languages works but if we do have one already, we will introduce confusion. how can you do that one-liner without introducing *ifNilOrEmpty:* ? Phil On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba tu...@tudorgirba.com wrote: This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection. A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty. Cheers, Doru On Mon, Jan 5, 2015 at 1:17 PM, Sebastian Sastre sebast...@flowingconcept.com wrote: taste is taste but would you care to illustrate your point with examples? I’m curious about it On Jan 5, 2015, at 6:12 AM, stepharo steph...@free.fr wrote: You summarise well the kind of code I do not like. isNil everywhere and horrible tests. Stef Le 4/1/15 23:27, Sebastian Sastre a écrit : Hi guys, I’ve started to use this little one: ObjectifNilOrEmpty: aBlock self ifNil: [ ^ aBlock value ]. (self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ]. ^ self. It allows you to do the widely known JavaScript one-liner: var stuff = this.thing || ‘some default value for when this.thing is undefined, null or an empty string’. but in smalltalk in this way: stuff := self thing ifNilOrEmpty: [ ‘some default value for when self thing is nil or an empty string’ ] simple thing feels practical and nice :) -- www.tudorgirba.com Every thing has its own flow -- --- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
On Mon, Jan 5, 2015 at 2:01 PM, Sebastian Sastre sebast...@flowingconcept.com wrote: On Jan 5, 2015, at 10:38 AM, p...@highoctane.be wrote: In business apps, the need for default values happen all the time, so the idiom has value (not sure for the message name though). Totally. In real apps, having to compare against uninitialized variable or nil as response or empty string happens so often that having this method makes it quite convenient (AKA lots of code becomes one-liners). We could use x := [ self thing ] ifError: [ someDefault ] I understand you’re setting a similar, quite not like it example but in any case this one raises and catches an exception and that sounds quite less efficient if compared to return self (when object is not nil and is not an empty collection/string) for these purposes. Triggering errors is not too nice still. Now, what if self itself is nil or empty? BTW, isEmptyOrNil exists in the image for Collections and UndefinedObject. Empty has no meaning for Object, so why test against empty in the name? Note that is not a testing method, it’s a conditional executor of the closure. The reason why was already mentioned, is to allow you to write this one-liner convenience: someVar := self thing ifNilOrEmpty: [blah] `self thing` could be an expensive process that returns something or nil or an empty collection. *If* you get nil or empty as result then you would get the block values resulting in having blah at someVar In the image, I see that we do have #default: anObject in several places. It seems to serve the same intent. What is the idiom for such things in Pharo? Importing idioms from other languages works but if we do have one already, we will introduce confusion. how can you do that one-liner without introducing *ifNilOrEmpty:* ? I'd agree to that for the use case you mention. Implementing it as Eliot recommends looks like the way to go. Phil Phil On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba tu...@tudorgirba.com wrote: This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection. A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty. Cheers, Doru On Mon, Jan 5, 2015 at 1:17 PM, Sebastian Sastre sebast...@flowingconcept.com wrote: taste is taste but would you care to illustrate your point with examples? I’m curious about it On Jan 5, 2015, at 6:12 AM, stepharo steph...@free.fr wrote: You summarise well the kind of code I do not like. isNil everywhere and horrible tests. Stef Le 4/1/15 23:27, Sebastian Sastre a écrit : Hi guys, I’ve started to use this little one: ObjectifNilOrEmpty: aBlock self ifNil: [ ^ aBlock value ]. (self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ]. ^ self. It allows you to do the widely known JavaScript one-liner: var stuff = this.thing || ‘some default value for when this.thing is undefined, null or an empty string’. but in smalltalk in this way: stuff := self thing ifNilOrEmpty: [ ‘some default value for when self thing is nil or an empty string’ ] simple thing feels practical and nice :) -- www.tudorgirba.com Every thing has its own flow -- --- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller -- --- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
Re: [Pharo-dev] On Twitter
You're quite right. I guess I should focus on *one thing* right now before it gets lost in the shuffle: Complete and publish my Amber tutorial. I have a lot of work ahead of me in this one. For the time being, I'll cut back on my tweets and Facebook and Google+. -- View this message in context: http://forum.world.st/On-Twitter-tp4797177p4797843.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Old inspector and explorer
since you’re working on this I really wish you could make the links yourself to get the right inspiration. You are the right guy for that. For everybody being critical of your own work is hard but is one of the most valuable things you can have. The vulgar thing is the opposite (being defensive) and that’s the road to mediocrity. In any case, sure, I can take notes on usability and share it with you. As a start and concrete example take anything that now requires one extra click or keystroke that before was not. On Jan 5, 2015, at 12:05 PM, Tudor Girba tu...@tudorgirba.com wrote: Hi Sebastian, I really do not see how your reply applies to the case at hand. If you have a concrete remark regarding how something is less useful now, please feel free to make it. Cheers, Doru On Mon, Jan 5, 2015 at 3:00 PM, Sebastian Sastre sebast...@flowingconcept.com mailto:sebast...@flowingconcept.com wrote: +1 Remember that “old” also means that it stands the test of time We need to be careful while innovating with the basics (workspace, inspecting, navigating code and debugging) because that impacts the whole economy of using this technology. Make productivity go up, never down! One additional click doesn’t sound like a lot but if that happens for something that you do 400 times a day is ~8000 times a month or ~60 minutes of clicking like crazy with overhead you didn’t have before. UX is King. No way back from that, it really rules (the only thing we have in control is what kingdom will we invent for it to rule) On Dec 26, 2014, at 2:42 PM, stepharo steph...@free.fr mailto:steph...@free.fr wrote: + 1 Debugging the rendering loops of Athens was such an example. In Bloc I get some race conditions with MC forked process... another fun one. Let people decide!!! Doru I DO NOT WANT TO LEARN WHAT I DO NOT WANT TO LEARN! I WANT to DECIDE WHEN. I control my agenda and my own schedule and my list is huge. Stef Doru, I think your intention is a good one but slightly misplaced. I really like the idea of GTInspector. It surely is a great tool and maybe I'll start to build my own inspector on my kind of things. To me the difference is between motivated to do or forced to do. Most of the time we are trying hard to solve our own problems. If in that progress other problems are forced upon us we get easily distracted and frustrated. The same goes for new tools. If I'm forced to use these it just means I have to deal with it first and only then I'm allowed to deal with my own problem. As it was in that special case the bug in nautilus and the new inspector made me shy away from developing something in 4.0 and now I'm back on 3.0. So I think the only possibility is to offer a new way of doing things and give people time to adjust. Norbert Am 26.12.2014 um 13:18 schrieb Tudor Girba tu...@tudorgirba.com mailto:tu...@tudorgirba.com: Hi, I think there must be a misunderstanding. There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use. There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore. What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear? But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger. Cheers, Doru On Thu, Dec 25, 2014 at 11:43 AM, stepharo steph...@free.fr mailto:steph...@free.fr wrote: I will add basicInspect in Object so that we can get access to the old inspector. I like that people can choose their tools! I mentioned that 20 times but people do not care apparently. Stef Le 23/12/14 11:50, Norbert Hartl a écrit : Is there a way to get the old tools
Re: [Pharo-dev] The Smalltalk Renaissance Program
Oh, I didn't realize you were focussed on older kids. I'm looking at introducing Smalltalk at the elementary school level, getting kids hooked on Smalltalk at an early age. Probably a full-blown Pharo or Squeak image would be overkill. stepharo wrote It depends what is the level you are looking for. We are working on lectures and books for second and third year university students. Now for kids I do not think that it matters if this the language or software is writting in Smalltalk. Stef Le 4/1/15 23:25, horrido a écrit : I am intrigued. Where can I find more info about Smalltalk education in the schools? I want to see what I can do in Canada. I presume there is a Smalltalk image customized for the classroom and aimed at elementary school students. That's what I'm hoping for. stepharo wrote ESUG is about the community. Without community then it is terrible. We set up also a program for teachers. Now in the US there is nearly nobody teaching smalltalk and this is a pity. -- View this message in context: http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797760.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. -- View this message in context: http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797846.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
On Mon, Jan 5, 2015 at 3:04 PM, Esteban A. Maringolo emaring...@gmail.com wrote: El Mon Jan 05 2015 at 10:50:48 AM, p...@highoctane.be p...@highoctane.be escribió: Why not put that into a Trait? TDefaultValueIdiomifEmptyOrNil: aDefaultObject So, if wanted,, one can put uses TDefaultValueIdiom (I am at a loss for a great name here, help!) and do as Sebastian proposes. This will prevent pollution of Object while at the same time being able to have the idiom available (and maybe with more than one form). But you can't hot plug a Trait to Object to have this behavior system-wide. Adding a trait involves recompilation AFAIR. Well, adding a Trait to Object doesn't work (dangerous change). But we can add that to objects we do control. Which may be good enough. P. The only thing I'd argue against is the naming. Otherwise is a very convenient method, when you go outside of the Smalltalk island and interact with API's not very well crafted or desgned to err on the safe side (empty collections instead o null), asking whether an object isNull or empty in the same method is really convenient. If we get purists, nil shouldn't exist either [1] and they should be replaced by domain specific abstractions representing the void/undefined. But we know there is a use case for nil, as IMO, there is a use case for isEmptyOrNil. However, whether you add it to Object in Pharo core image or not isn't really relevant, whoever wants/needs it can add it afterwards. Regards, [1] http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare
[Pharo-dev] Essay Topics
As promised, here is my first list of essay topics. I would like to ask you to submit an essay on one of these topics. Multiple submissions are welcome; if they're good, they will all get published at Smalltalk Renaissance. I will edit the articles for grammar and style. You should look good after I'm done. There's no deadline, but obviously the sooner you can write them, the better. SRP is a fast-moving campaign. If you have other suggestions for essay topics, please let me know. Without further ado, here are the topics... Topic #1: How do modern IDEs, such as Eclipse and IntelliJ and Visual Studio, compare with the tried-and-true Smalltalk development environment? - Topic #2: It is the contention of some critics, including Robert Martin https://www.youtube.com/watch?v=YX3iRjKj7C0 , that Smalltalk did not (does not?) address the needs of the enterprise. Present a counter-argument. Explain how Smalltalk can assist the enterprise in team development, in large-scale development, and in integrating with existing (typically Windows-based) infrastructures. Pay particular attention to the question of RDBMS usage, which is often critical in the enterprise. - Topic #3: Some critics complain that Smalltalk does not play well with existing file-based tooling. /Duh!/ Smalltalk is a new approach to IDEs and software engineering. We should be advancing this paradigm with new tooling, rather than falling back on the old again and again. Otherwise, things will never change for the better. Make a case for why we should embrace this change now, rather than waiting (for what?). Also, this webpage http://thoughtstorms.info/view/smalltalkunix/view/smalltalk poses an interesting argument against Smalltalk. Perhaps someone can tackle it. - Topic #4: In the age of multi-core processors and concurrency programming, how is Smalltalk addressing the concerns of developers? - Topic #5: How should we address the issue of compatibility (ie, fragmentation) among various implementations of Smalltalk? Does this issue hamper the creation of an ecosystem of libraries and shared code? -- View this message in context: http://forum.world.st/Essay-Topics-tp4797847.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
On Jan 5, 2015, at 12:07 PM, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 05 Jan 2015, at 12:06 , Sebastian Sastre sebast...@flowingconcept.com mailto:sebast...@flowingconcept.com wrote: but not putting it on Object would change the feature since you do want it returning self on that case. No. In that case, you want to use ifNil: , not ifNilOrEmpty:. The only thing Object ifNilOrEmpty would support, is putting both collections and non-collection in the same variable, which is usually a bad idea to begin with, since it will lead to are you a collection or single instance? checks in almost every user of said variable. Hi Henry, I think you are talking of a different feature or maybe promoting that things should not be treated as possibly nil or empty collections which is understandable but I’m treating the programers as good citizens that know what they do and bear the consequences (not as beasts that should be educated or indoctrinated or prevented on how to use code and do things) Whatever the case does your idea pass this test? testIfNilOrEmpty | stuff thing | stuff := nil. self assert: stuff equals: nil. self assert: thing equals: nil. thing := stuff ifNilOrEmpty: [ 42 ]. self assert: thing equals: 42. stuff := 1984. thing := stuff ifNilOrEmpty: [ 42 ]. self deny: thing = nil. self assert: thing equals: 1984. self deny: thing = 42.
Re: [Pharo-dev] The Smalltalk Renaissance Program
Maybe Phratch? Then maybe they start looking under the hood? http://www.phratch.com/ On Mon, Jan 5, 2015 at 10:31 PM, horrido horrido.hobb...@gmail.com wrote: Oh, I didn't realize you were focussed on older kids. I'm looking at introducing Smalltalk at the elementary school level, getting kids hooked on Smalltalk at an early age. Probably a full-blown Pharo or Squeak image would be overkill. stepharo wrote It depends what is the level you are looking for. We are working on lectures and books for second and third year university students. Now for kids I do not think that it matters if this the language or software is writting in Smalltalk. Stef Le 4/1/15 23:25, horrido a écrit : I am intrigued. Where can I find more info about Smalltalk education in the schools? I want to see what I can do in Canada. I presume there is a Smalltalk image customized for the classroom and aimed at elementary school students. That's what I'm hoping for. stepharo wrote ESUG is about the community. Without community then it is terrible. We set up also a program for teachers. Now in the US there is nearly nobody teaching smalltalk and this is a pity. -- View this message in context: http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797760.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. -- View this message in context: http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797846.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] On Twitter
On 05 Jan 2015, at 15:28, horrido horrido.hobb...@gmail.com wrote: You're quite right. I guess I should focus on *one thing* right now before it gets lost in the shuffle: Complete and publish my Amber tutorial. I have a lot of work ahead of me in this one. Not that I have anything against Amber, but why pick that one ? Everybody seems to think something along the lines of 'JavaScript is very popular, if only we get on that platform and we'll be all set' - I don't think that is the case. Even Amber's original developer is now working full time on JavaScript, yet does no longer seem to use it. Also, on technical grounds it could be argued that Amber misses a number of critical Smalltalk features (thisContext, #become:). Furthermore, it is slower and has a only a limited IDE. Other than that, focus is good. For the time being, I'll cut back on my tweets and Facebook and Google+.
Re: [Pharo-dev] Old inspector and explorer
On 05 Jan 2015, at 15:31, Sebastian Sastre sebast...@flowingconcept.com wrote: since you’re working on this I really wish you could make the links yourself to get the right inspiration. You are the right guy for that. For everybody being critical of your own work is hard but is one of the most valuable things you can have. The vulgar thing is the opposite (being defensive) and that’s the road to mediocrity. In any case, sure, I can take notes on usability and share it with you. As a start and concrete example take anything that now requires one extra click or keystroke that before was not. Doru is anything but defensive. He literally asks for concrete examples. The goal is to make the workflow better for everyone. On Jan 5, 2015, at 12:05 PM, Tudor Girba tu...@tudorgirba.com wrote: Hi Sebastian, I really do not see how your reply applies to the case at hand. If you have a concrete remark regarding how something is less useful now, please feel free to make it. Cheers, Doru On Mon, Jan 5, 2015 at 3:00 PM, Sebastian Sastre sebast...@flowingconcept.com wrote: +1 Remember that “old” also means that it stands the test of time We need to be careful while innovating with the basics (workspace, inspecting, navigating code and debugging) because that impacts the whole economy of using this technology. Make productivity go up, never down! One additional click doesn’t sound like a lot but if that happens for something that you do 400 times a day is ~8000 times a month or ~60 minutes of clicking like crazy with overhead you didn’t have before. UX is King. No way back from that, it really rules (the only thing we have in control is what kingdom will we invent for it to rule) On Dec 26, 2014, at 2:42 PM, stepharo steph...@free.fr wrote: + 1 Debugging the rendering loops of Athens was such an example. In Bloc I get some race conditions with MC forked process... another fun one. Let people decide!!! Doru I DO NOT WANT TO LEARN WHAT I DO NOT WANT TO LEARN! I WANT to DECIDE WHEN. I control my agenda and my own schedule and my list is huge. Stef Doru, I think your intention is a good one but slightly misplaced. I really like the idea of GTInspector. It surely is a great tool and maybe I'll start to build my own inspector on my kind of things. To me the difference is between motivated to do or forced to do. Most of the time we are trying hard to solve our own problems. If in that progress other problems are forced upon us we get easily distracted and frustrated. The same goes for new tools. If I'm forced to use these it just means I have to deal with it first and only then I'm allowed to deal with my own problem. As it was in that special case the bug in nautilus and the new inspector made me shy away from developing something in 4.0 and now I'm back on 3.0. So I think the only possibility is to offer a new way of doing things and give people time to adjust. Norbert Am 26.12.2014 um 13:18 schrieb Tudor Girba tu...@tudorgirba.com: Hi, I think there must be a misunderstanding. There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use. There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore. What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear? But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger. Cheers, Doru On Thu, Dec 25, 2014 at 11:43 AM, stepharo steph...@free.fr wrote: I will add basicInspect in Object so that we can get access to the old inspector. I like that people can choose their tools! I mentioned that 20 times but people do not care
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
On 05 Jan 2015, at 3:46 , Sebastian Sastre sebast...@flowingconcept.com wrote: On Jan 5, 2015, at 12:07 PM, Henrik Johansen henrik.s.johan...@veloxit.no mailto:henrik.s.johan...@veloxit.no wrote: On 05 Jan 2015, at 12:06 , Sebastian Sastre sebast...@flowingconcept.com mailto:sebast...@flowingconcept.com wrote: but not putting it on Object would change the feature since you do want it returning self on that case. No. In that case, you want to use ifNil: , not ifNilOrEmpty:. The only thing Object ifNilOrEmpty would support, is putting both collections and non-collection in the same variable, which is usually a bad idea to begin with, since it will lead to are you a collection or single instance? checks in almost every user of said variable. Hi Henry, I think you are talking of a different feature or maybe promoting that things should not be treated as possibly nil or empty collections which is understandable but I’m treating the programers as good citizens that know what they do and bear the consequences (not as beasts that should be educated or indoctrinated or prevented on how to use code and do things) No, I'm talking about exactly what I quoted, implementing ifNilOrEmpty: on just UndefinedObject/Collection, but not Object. Doing that is not about indoctrinating, but preventing bad code resulting from using the same variable to hold non-polymorphic objects. Whatever the case does your idea pass this test? testIfNilOrEmpty | stuff thing | stuff := nil. self assert: stuff equals: nil. self assert: thing equals: nil. thing := stuff ifNilOrEmpty: [ 42 ]. self assert: thing equals: 42. stuff := 1984. thing := stuff ifNilOrEmpty: [ 42 ]. self deny: thing = nil. self assert: thing equals: 1984. self deny: thing = 42. Of course, since my idea was to use ifNil: when the variable you are dealing with is not Collections. Cheers, Henry
Re: [Pharo-dev] On Twitter
On Mon, Jan 5, 2015 at 3:57 PM, Sven Van Caekenberghe s...@stfx.eu wrote: On 05 Jan 2015, at 15:28, horrido horrido.hobb...@gmail.com wrote: You're quite right. I guess I should focus on *one thing* right now before it gets lost in the shuffle: Complete and publish my Amber tutorial. I have a lot of work ahead of me in this one. Not that I have anything against Amber, but why pick that one ? Everybody seems to think something along the lines of 'JavaScript is very popular, if only we get on that platform and we'll be all set' - I don't think that is the case. Even Amber's original developer is now working full time on JavaScript, yet does no longer seem to use it. Hey, Amber is alive! 0.14 just out. Herby does a good job, examples are refined, we are injecting effort in it. It takes a while to get things to 1.0. We can't afford to pass on SPAs and it is not with Seaside that we'll do it. Also, on technical grounds it could be argued that Amber misses a number of critical Smalltalk features (thisContext, #become:). Furthermore, it is slower and has a only a limited IDE. thisContext and become: aren't in but even like that, the prototyping power of Amber is strong even if tooling can be improved (first the core, then the bells and whistles). Javascript also has features that Smalltalk doesn't have. So, it is a give or take game. If anything, Amber helps one into understanding the current Javascript ways in a quite good manner. It does for me. Other than that, focus is good. For the time being, I'll cut back on my tweets and Facebook and Google+.
Re: [Pharo-dev] On Twitter
That's a really, really good idea! Thanks! sebast...@flowingconcept.com wrote On Jan 5, 2015, at 2:02 PM, Sven Van Caekenberghe lt; sven@ gt; wrote: Just wondering, did you actually see this page: http://pharo.org/success lt;http://pharo.org/successgt; ? This is all real, commercially successful stuff. Not that we don't need more traction, but it is important to understand and know what is already there. +1 That’s a good starting point Richard. Idea: if you interview the people beyond those cases it will make everything more interesting for everybody -- View this message in context: http://forum.world.st/On-Twitter-tp4797177p4797875.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Essay Topics
Oh, I forgot to mention. Please notify me of your topic choice at my personal email: horrido.hobbies at gmail dot com. That way, I can coordinate the essay activities. Thanks. -- View this message in context: http://forum.world.st/Essay-Topics-tp4797847p4797876.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] [Bulk] [Bulk] Can MongoTalk execute plan javascript MongoDB queries?
Hi Eliot,
Am 05.01.2015 um 16:59 schrieb Eliot Miranda eliot.mira...@gmail.com:
Hi Norbert,
this reminds me of something IIRC that Alan Knight did in TopLink, a
commercial OR mapping tool. Alan allowed one to write queries in
conventional Smalltalk such as
db select: [:obj| obj name = 'foo' or: [obj feature isSomething]]
but under the covers compiling this block into a query that the database
could execute by evaluating the block once, passing in a compiling object
that implements doesNotUnderstand: to catch the messages sent in the block.
That technique could work in this context and avoid introducing the (excuse
me for saying, /horrible/) tuple syntax.
IIRC I used that in Glorp as well (which is the open source successor of
TopLink, right?)
We have that, too. It is called MongoQueries and has been done by Nicholas
Petton. For basic usage like your example above it works perfectly. But if it
comes to special nested accessors or complex queries you end up having problems
really quick. I think with a little love the MongoQueries package can easily be
extended to support a fair amount of use cases.
You are right, the nested dictionaries are awful but those smalltalk DSL
mapping queries are really restricted and hard to make them powerful. So it is
again the choice between beelzebub and the devil (as we say).
Norbert
Eliot (phone)
On Jan 5, 2015, at 4:41 AM, Norbert Hartl norb...@hartl.name wrote:
Am 05.01.2015 um 04:59 schrieb Yanni Chiu ya...@rogers.com:
On Jan 4, 2015, at 4:38 AM, Norbert Hartl norb...@hartl.name wrote:
someCollection select: {
'$or' - {
{ 'name' - {
'$regex' - 'test' .
'$options' - 'i' } asDictionary } asDictionary.
{ 'description' - {
'$regex' - 'test' .
'$options' - 'i' } asDictionary } asDictionary
}
} asDictionary
That worked. I was close, but I was using $or: instead of $or, and I was
missing one level of asDictionary.
Just for the archive, there’s one more query I needed, which was to find an
object based on it’s object id. I ended up using:
voyageId := Integer readFrom: (request at: #voyageId) base: 16.
someModel := SomeModel selectOne: { '_id' - (OID value: voyageId) }
asDictionary.
This is a web app using Teapot and Mustache, so I write the voyageId out
using:
self voyageId value printStringHex
Sounds cool. If you have anything to publish I'm interested what you've
done. Especially if you have some nice tricks doing form handling in teapot.
Btw. for the archive. A common use case I encounter is to query objects that
are being referenced by another object. It works like this
AnyClass#referencedBy: anObject
^ AnyClass selectMany: {
'reference.__id' - anObject voyageId } asDictionary
Norbert
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
On 05 Jan 2015, at 5:07 , Sebastian Sastre sebast...@flowingconcept.com wrote: On Jan 5, 2015, at 1:48 PM, Henrik Johansen henrik.s.johan...@veloxit.no mailto:henrik.s.johan...@veloxit.no wrote: On 05 Jan 2015, at 4:20 , Sebastian Sastre sebast...@flowingconcept.com mailto:sebast...@flowingconcept.com wrote: Ah Henry but you are making the code to know if it’s a collection or not, I talking about making the code specifically to ignore that. Why that would lead to bad code? can you elaborate or put examples instead of adjectives? I did that already: I took a look at the thread and I don’t see examples of bad code I’m still curious about what you mean by that Are you joking? I quoted the elaboration on what I mean by bad code... Cheers, Henry
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
On 05 Jan 2015, at 5:37 , Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 05 Jan 2015, at 5:07 , Sebastian Sastre sebast...@flowingconcept.com mailto:sebast...@flowingconcept.com wrote: On Jan 5, 2015, at 1:48 PM, Henrik Johansen henrik.s.johan...@veloxit.no mailto:henrik.s.johan...@veloxit.no wrote: On 05 Jan 2015, at 4:20 , Sebastian Sastre sebast...@flowingconcept.com mailto:sebast...@flowingconcept.com wrote: Ah Henry but you are making the code to know if it’s a collection or not, I talking about making the code specifically to ignore that. Why that would lead to bad code? can you elaborate or put examples instead of adjectives? I did that already: I took a look at the thread and I don’t see examples of bad code I’m still curious about what you mean by that Are you joking? I quoted the elaboration on what I mean by bad code... Cheers, Henry Just in case there's something weird with your mail client, it was: it will lead to are you a collection or single instance? checks in almost every user of said variable. Which is unneccessary pain compared to using a collection with a single entry if that's what you mean instead, and have all users expect a collection of items to deal with. So you'd do: stuff: aCollection stuff := aCollection ifNilOrEmpty: [Default collection #(1 2 3)] which will raise an error if you pass in, say, Object new as pishPosh, instead of leaving each user of stuff to determine whether stuff is a collection, an object, or nil. Of course, you can still do nonsense like stuff := aCollection ifNilOrEmpty: [42] but at least *that* problem is easier to pinpoint when later, a debugger with a user of stuff that expected it to be a collection pops up. If the origin of stuff as a single instance is lost to the mists of time (say, Object implements ifNilOrEmpty: and someone called stuff: with an Object without error), it's easier to end up with a solution of fixing the use to (stuff isKindOf: Collection) or is that isCollection? ifTrue: [Code handling each entry] ifFalse: [Code handling single instance] And now there's two stinks. Cheers, Henry
Re: [Pharo-dev] Wrapping RegQueryValueExA in NativeBoost
Hi,
Happy new year too!
I succeeded to have a working example. I wrote the code but I can't commit it.
Can you add me on the project please?
Just to give some indications for the code I changed.
Globally the primitive call is good. But when you pass 'nil' as argument for
the primitive, it will not be converted to 'null' ('null' have for value 0). To
have the 0, either you change nil into 0 or you add the option
#optCoerceNilToNull in the call (because it is not the default...) (See
'NBNativeCodeGen classdefaultOptions' for the others). It is the mainly
problem!
Concerning the arguments allocation there is some tips:
'NativeBoost allocate: number' allocates a memory segment of the size given
by number and return the address to it.
But it is better to use 'NativeBoost allocate: (NBExternalType sizeOf:
'ulong')' or 'NativeBoost allocate: (NBExternalType sizeOf: 'DWORD')' for both
dwType and lSize arguments.
With some advance, you will see in the example4 that the RegQueryValueExA
doesn't return a valid error value... I don't know why...
I hope it will be helpful,
Cheers,
Vincent
-Message d'origine-
De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de Torsten
Bergmann
Envoyé : dimanche 4 janvier 2015 21:43
À : Pharo Development List
Objet : [Pharo-dev] Wrapping RegQueryValueExA in NativeBoost
Hi,
Happy new year!
I try to wrap some API methods using NativeBoost to access Win32 Registry and
broaden the Pharo support for Windows. Currently I'm already able to
- create registry keys (RegCreateKeyA API)
- open registry keys (RegOpenKeyExA API)
- delete registry keys (RegDeleteKeyA API)
- close registry key handles (RegCloseKey API)
Now I additionally want to query some keys using the RegQueryValueExA API
(http://msdn.microsoft.com/en-us/library/windows/desktop/ms724911%28v=vs.85%29.aspx).
As I tried an example in an elder Smalltalk/MT first (see attached) I know it
is working from the Win32 API side.
My NativeBoost definition in Pharo for wrapping the function looks like this
(similar to MSDN):
regQueryValueExA: hKey with: lpValueName with: lpReserved with: lpType with:
lpData with: lpcbData
primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'
^ self nbCall: #(LONG RegQueryValueExA(
HKEY hKey,
LPCTSTR lpValueName,
LPDWORD lpReserved,
LPDWORD lpType,
LPBYTE lpData,
LPDWORD lpcbData)) module: #advapi32
But when I call it I get a Generic error thrown by NB and independent how
hard I try I can not get this call to work in NativeBoost. I checked all
arguments, checked the type definitions (pool WinTypes which is similar to
NBWinTypes), played with options, ... but was not able to find out what I'm
doing wrong in Pharo. Meanwhile after investing several days of my spare time
it looks like I cant see the wood because of all the trees.
I would really appreciate if someone with enough knowledge of NativeBoost could
have a second look to point my into the right direction.
To reproduce:
=
- use a fresh Pharo4.0 Latest update: #40428
- open World menu - Configuration Browser and load OSWindows project
- go to class WinRegistry
- there is the NativeBoost API definition in method
#regQueryValueExA:with:with:with:with:with:
- and a method #example2 that calls this in a similar way as in my
Smalltalk/MT example
(if you try this example you get the Generic error)
Many thanks in advance!
Bye
T.
Ce message et les pièces jointes sont confidentiels et réservés à l'usage
exclusif de ses destinataires. Il peut également être protégé par le secret
professionnel. Si vous recevez ce message par erreur, merci d'en avertir
immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant
être assurée sur Internet, la responsabilité de Worldline ne pourra être
recherchée quant au contenu de ce message. Bien que les meilleurs efforts
soient faits pour maintenir cette transmission exempte de tout virus,
l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne
saurait être recherchée pour tout dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for
the addressee; it may also be privileged. If you receive this e-mail in error,
please notify the sender immediately and destroy it. As its integrity cannot be
secured on the Internet, the Worldline liability cannot be triggered for the
message content. Although the sender endeavours to maintain a computer
virus-free network, the sender does not warrant that this transmission is
virus-free and will not be liable for any damages resulting from any virus
transmitted.
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
in any case, we already have the idiom #isEmptyOrNil (btw, in pharo4 it was removed from Object and I don’t know why, but is still in Collection and in UndefinedObject). So, in case of adding it, the correct implementation should be: 1) restore Object#isEmptyOrNil ^ false 2) implement: Object#ifEmptyOrNil: aBlock self isEmptyOrNil ifTrue: aBlock. ^ self which IMO is the clean way to implement such idiom. said that, I will go back to my vacations :) Esteban On 05 Jan 2015, at 15:47, Esteban A. Maringolo emaring...@gmail.com wrote: El Mon Jan 05 2015 at 3:36:50 PM, stepharo steph...@free.fr mailto:steph...@free.fr escribió: This is not because some people may not know how to program in other languages that we should copy that. I share your taste for this kind of code. But this purist approach raises the bar leaving out a lot of developers with poor design/modelling skills. The more 1:1 mappings they can bring in from their previous language of choice, the better, and higher the odds they'll clinge on Pharo and continue using it. To make both sides of this discussion happy I think the base image shouldn't include this, and there can be an extra package with these language extensions. Regards!
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
Hi, As discussed in this thread, I do not see a reason for implementing this method in Object. Having it in Collection/UndefinedObject can make some sense (although I do not really like it) for working with variables that can be either collection or nil. Cheers, Doru On Mon, Jan 5, 2015 at 8:59 PM, Esteban Lorenzano esteba...@gmail.com wrote: in any case, we already have the idiom #isEmptyOrNil (btw, in pharo4 it was removed from Object and I don’t know why, but is still in Collection and in UndefinedObject). So, in case of adding it, the correct implementation should be: 1) restore Object#isEmptyOrNil ^ false 2) implement: Object#ifEmptyOrNil: aBlock self isEmptyOrNil ifTrue: aBlock. ^ self which IMO is the clean way to implement such idiom. said that, I will go back to my vacations :) Esteban On 05 Jan 2015, at 15:47, Esteban A. Maringolo emaring...@gmail.com wrote: El Mon Jan 05 2015 at 3:36:50 PM, stepharo steph...@free.fr escribió: This is not because some people may not know how to program in other languages that we should copy that. I share your taste for this kind of code. But this purist approach raises the bar leaving out a lot of developers with poor design/modelling skills. The more 1:1 mappings they can bring in from their previous language of choice, the better, and higher the odds they'll clinge on Pharo and continue using it. To make both sides of this discussion happy I think the base image shouldn't include this, and there can be an extra package with these language extensions. Regards! -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
probably, but in any case it has to be implemented using existing idioms, not repeating code, which was the core of my point. crap. I really need to turn off my computer or I will continue watching mails ;) Esteban On 05 Jan 2015, at 17:25, Tudor Girba tu...@tudorgirba.com wrote: Hi, As discussed in this thread, I do not see a reason for implementing this method in Object. Having it in Collection/UndefinedObject can make some sense (although I do not really like it) for working with variables that can be either collection or nil. Cheers, Doru On Mon, Jan 5, 2015 at 8:59 PM, Esteban Lorenzano esteba...@gmail.com mailto:esteba...@gmail.com wrote: in any case, we already have the idiom #isEmptyOrNil (btw, in pharo4 it was removed from Object and I don’t know why, but is still in Collection and in UndefinedObject). So, in case of adding it, the correct implementation should be: 1) restore Object#isEmptyOrNil ^ false 2) implement: Object#ifEmptyOrNil: aBlock self isEmptyOrNil ifTrue: aBlock. ^ self which IMO is the clean way to implement such idiom. said that, I will go back to my vacations :) Esteban On 05 Jan 2015, at 15:47, Esteban A. Maringolo emaring...@gmail.com mailto:emaring...@gmail.com wrote: El Mon Jan 05 2015 at 3:36:50 PM, stepharo steph...@free.fr mailto:steph...@free.fr escribió: This is not because some people may not know how to program in other languages that we should copy that. I share your taste for this kind of code. But this purist approach raises the bar leaving out a lot of developers with poor design/modelling skills. The more 1:1 mappings they can bring in from their previous language of choice, the better, and higher the odds they'll clinge on Pharo and continue using it. To make both sides of this discussion happy I think the base image shouldn't include this, and there can be an extra package with these language extensions. Regards! -- www.tudorgirba.com http://www.tudorgirba.com/ Every thing has its own flow
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
but not putting it on Object would change the feature since you /do want it/ returning self on that case. No. In that case, you want to use ifNil: , not ifNilOrEmpty:. The only thing Object ifNilOrEmpty would support, is putting both collections and non-collection in the same variable, which is usually a bad idea to begin with, since it will lead to are you a collection or single instance? checks in almost every user of said variable. + 100. Cheers, Henry
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
Hi Henry, I think you are talking of a different feature or maybe promoting that things should not be treated as possibly nil or empty collections which is understandable but I’m treating the programers as good citizens that know what they do and bear the consequences (not as beasts that should be educated or indoctrinated or prevented on how to use code and do things) No, I'm talking about exactly what I quoted, implementing ifNilOrEmpty: on just UndefinedObject/Collection, but not Object. Doing that is not about indoctrinating, but preventing bad code resulting from using the same variable to hold non-polymorphic objects. I thought the same :) Thanks Henry I love your view on the world.
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
taste is taste but would you care to illustrate your point with examples? I’m curious about it Henry did it well.
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
On Jan 5, 2015, at 2:56 PM, Henrik Johansen henrik.s.johan...@veloxit.no wrote: Of course, you can still do nonsense like stuff := aCollection ifNilOrEmpty: [42] but at least *that* problem is easier to pinpoint when later, a debugger with a user of stuff that expected it to be a collection pops up. If the origin of stuff as a single instance is lost to the mists of time (say, Object implements ifNilOrEmpty: and someone called stuff: with an Object without error), it's easier to end up with a solution of fixing the use to (stuff isKindOf: Collection) or is that isCollection? ifTrue: [Code handling each entry] ifFalse: [Code handling single instance] And now there's two stinks. Cheers, Henry Ah, right. I get your point now. I'd see that as an abuse. I’ve mentioned a couple of examples before, the “good” uses of this convenience are meant for handling the empty string or nil frequent case and APIs that are more functionally inspired (like when they use an Option / Some / None / Nothing as response and you need to normalize that into smalltalk style)
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
Guys Do you think that Pharo does not have the complexity of a real app? :) Now seriously if you have to deal with external values, then this is the job of the importer to import and put polymorphic default in variable. Putting nil or emtpy collection in a collection is a recipe to disaster. All clients will have to check and you can avoid that simply. Put an empty collection. This is not because some people may not know how to program in other languages that we should copy that. Stef Le 5/1/15 14:01, Sebastian Sastre a écrit : On Jan 5, 2015, at 10:38 AM, p...@highoctane.be mailto:p...@highoctane.be wrote: In business apps, the need for default values happen all the time, so the idiom has value (not sure for the message name though). Totally. In real apps, having to compare against uninitialized variable or nil as response or empty string happens so often that having this method makes it quite convenient (AKA lots of code becomes one-liners). We could use x := [ self thing ] ifError: [ someDefault ] I understand you’re setting a similar, quite not like it example but in any case this one raises and catches an exception and that sounds quite less efficient if compared to return self (when object is not nil and is not an empty collection/string) for these purposes. Triggering errors is not too nice still. Now, what if self itself is nil or empty? BTW, isEmptyOrNil exists in the image for Collections and UndefinedObject. Empty has no meaning for Object, so why test against empty in the name? Note that is not a testing method, it’s a conditional executor of the closure. The reason why was already mentioned, is to allow you to write this one-liner convenience: someVar := self thing ifNilOrEmpty: [blah] `self thing` could be an expensive process that returns something or nil or an empty collection. *If* you get nil or empty as result then you would get the block values resulting in having blah at someVar In the image, I see that we do have #default: anObject in several places. It seems to serve the same intent. What is the idiom for such things in Pharo? Importing idioms from other languages works but if we do have one already, we will introduce confusion. how can you do that one-liner without introducing *ifNilOrEmpty:* ? Phil On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba tu...@tudorgirba.com mailto:tu...@tudorgirba.com wrote: This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection. A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty. Cheers, Doru On Mon, Jan 5, 2015 at 1:17 PM, Sebastian Sastre sebast...@flowingconcept.com mailto:sebast...@flowingconcept.com wrote: taste is taste but would you care to illustrate your point with examples? I’m curious about it On Jan 5, 2015, at 6:12 AM, stepharo steph...@free.fr mailto:steph...@free.fr wrote: You summarise well the kind of code I do not like. isNil everywhere and horrible tests. Stef Le 4/1/15 23:27, Sebastian Sastre a écrit : Hi guys, I’ve started to use this little one: ObjectifNilOrEmpty: aBlock self ifNil: [ ^ aBlock value ]. (self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ]. ^ self. It allows you to do the widely known JavaScript one-liner: var stuff = this.thing || ‘some default value for when this.thing is undefined, null or an empty string’. but in smalltalk in this way: stuff := self thing ifNilOrEmpty: [ ‘some default value for when self thing is nil or an empty string’ ] simple thing feels practical and nice :) -- www.tudorgirba.com http://www.tudorgirba.com/ Every thing has its own flow -- --- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be mailto:mail%3ap...@highoctane.be | Web: http://philippeback.eu http://philippeback.eu/ Blog: http://philippeback.be http://philippeback.be/ | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com http://spamcast.libsyn.com/ Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
Of course. If you know what you are doing you will not abuse it and it will not be a recipe for disaster. You can also make recipes for disaster putting globals in Smalltalk, abusing #become: nesting ifTrue: etc etc etc which is stuff that is already there decades ago The shared convenience is for who feels it convenient. That usually happens when you have to deal with APIs which design that are out of your control and you use it to normalize it conveniently (AKA in a cheap one-liner hence this method) On Jan 5, 2015, at 4:36 PM, stepharo steph...@free.fr wrote: Guys Do you think that Pharo does not have the complexity of a real app? :) Now seriously if you have to deal with external values, then this is the job of the importer to import and put polymorphic default in variable. Putting nil or emtpy collection in a collection is a recipe to disaster. All clients will have to check and you can avoid that simply. Put an empty collection. This is not because some people may not know how to program in other languages that we should copy that. Stef Le 5/1/15 14:01, Sebastian Sastre a écrit : On Jan 5, 2015, at 10:38 AM, p...@highoctane.be mailto:p...@highoctane.be wrote: In business apps, the need for default values happen all the time, so the idiom has value (not sure for the message name though). Totally. In real apps, having to compare against uninitialized variable or nil as response or empty string happens so often that having this method makes it quite convenient (AKA lots of code becomes one-liners). We could use x := [ self thing ] ifError: [ someDefault ] I understand you’re setting a similar, quite not like it example but in any case this one raises and catches an exception and that sounds quite less efficient if compared to return self (when object is not nil and is not an empty collection/string) for these purposes. Triggering errors is not too nice still. Now, what if self itself is nil or empty? BTW, isEmptyOrNil exists in the image for Collections and UndefinedObject. Empty has no meaning for Object, so why test against empty in the name? Note that is not a testing method, it’s a conditional executor of the closure. The reason why was already mentioned, is to allow you to write this one-liner convenience: someVar := self thing ifNilOrEmpty: [blah] `self thing` could be an expensive process that returns something or nil or an empty collection. If you get nil or empty as result then you would get the block values resulting in having blah at someVar In the image, I see that we do have #default: anObject in several places. It seems to serve the same intent. What is the idiom for such things in Pharo? Importing idioms from other languages works but if we do have one already, we will introduce confusion. how can you do that one-liner without introducing ifNilOrEmpty: ? Phil On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba tu...@tudorgirba.com mailto:tu...@tudorgirba.com wrote: This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection. A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty. Cheers, Doru On Mon, Jan 5, 2015 at 1:17 PM, Sebastian Sastre sebast...@flowingconcept.com mailto:sebast...@flowingconcept.com wrote: taste is taste but would you care to illustrate your point with examples? I’m curious about it On Jan 5, 2015, at 6:12 AM, stepharo steph...@free.fr mailto:steph...@free.fr wrote: You summarise well the kind of code I do not like. isNil everywhere and horrible tests. Stef Le 4/1/15 23:27, Sebastian Sastre a écrit : Hi guys, I’ve started to use this little one: ObjectifNilOrEmpty: aBlock self ifNil: [ ^ aBlock value ]. (self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ]. ^ self. It allows you to do the widely known JavaScript one-liner: var stuff = this.thing || ‘some default value for when this.thing is undefined, null or an empty string’. but in smalltalk in this way: stuff := self thing ifNilOrEmpty: [ ‘some default value for when self thing is nil or an empty string’ ] simple thing feels practical and nice :) -- www.tudorgirba.com http://www.tudorgirba.com/ Every thing has its own flow -- --- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be mailto:mail%3ap...@highoctane.be | Web: http://philippeback.eu http://philippeback.eu/ Blog: http://philippeback.be http://philippeback.be/ | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
El Mon Jan 05 2015 at 3:36:50 PM, stepharo steph...@free.fr escribió: This is not because some people may not know how to program in other languages that we should copy that. I share your taste for this kind of code. But this purist approach raises the bar leaving out a lot of developers with poor design/modelling skills. The more 1:1 mappings they can bring in from their previous language of choice, the better, and higher the odds they'll clinge on Pharo and continue using it. To make both sides of this discussion happy I think the base image shouldn't include this, and there can be an extra package with these language extensions. Regards!
Re: [Pharo-dev] Wrapping RegQueryValueExA in NativeBoost
Hi Vincent,
I succeeded to have a working example. I wrote the code but I can't commit
it. Can you add me on the project please?
I added the account VincentBlondeau to STHub project. You should be able to
commit.
Just to give some indications for the code I changed.
Globally the primitive call is good. But when you pass 'nil' as argument for
the primitive, it will not be converted to 'null' ('null' have for value 0).
To have the 0, either you change nil into 0 or you add the option
#optCoerceNilToNull in the call (because it is not the default...) (See
'NBNativeCodeGen classdefaultOptions' for the others). It is the mainly
problem!
But I tried this already. When I
- switch to 0 in the calling method #example2
- or switch to 0 directly in the RegQueryValueExA wraper
- or use the option optCoerceNilToNull
I still get the generic error.
Concerning the arguments allocation there is some tips:
'NativeBoost allocate: number' allocates a memory segment of the size given
by number and return the address to it.
But it is better to use 'NativeBoost allocate: (NBExternalType sizeOf:
'ulong')' or 'NativeBoost allocate: (NBExternalType sizeOf: 'DWORD')' for
both dwType and lSize arguments.
Yes, thats clear. I usually try to make it make it run make it right make it
fast, currently I struggle with
the first here. ;)
With some advance, you will see in the example4 that the RegQueryValueExA
doesn't return a valid error value... I don't know why...
Commit the code where the call works and I can check. Step by step ...
I hope it will be helpful,
I really appreciate your feedback! Thanks
Regards
Torsten
Re: [Pharo-dev] The Smalltalk Renaissance Program
I just went through a few of the Waveplace videos. I am impressed. They are truly excellent videos and I can see how they can engage youngsters and gently introduce programming concepts to them. Why aren't these being used in Canadian elementary schools??? I shall have to ask. Beyond the early grades, students can continue learning programming with Pharo. I see this as a smooth migration. This is getting exciting! Aaron Rosenzweig wrote Hi, The Squeak images tend to be more tuned towards grade-school education. In particular, “eToys” sits on top of smalltalk and is perfect for young elementary school students to take their first steps in computer programming. My children went through the “waveplace” video tutorials. They did the beta one which was more in depth and had like 30 videos if I remember correctly. Pharo is more “professional.” Not to say there is anything wrong with Squeak, it was used for DabbleDB… It’s just that most developers don’t want to see a mouse with eyeballs following your cursor when you first launch the image. You can remove that from the image, etc. but it’s that first feel. Overall Squeak seems like it blends in better in the classroom and Pharo suits developers more. I’ll probably be flamed for saying it but realize it’s a high level generalization. I know there is more going on underneath and I know that Pharo is the primary target for Seaside, etc. Both Squeak and Pharo are nice. AARON ROSENZWEIG / Chat 'n Bike e: aaron@ t: (301) 956-2319 On Jan 4, 2015, at 5:25 PM, horrido lt; horrido.hobbies@ gt; wrote: I am intrigued. Where can I find more info about Smalltalk education in the schools? I want to see what I can do in Canada. I presume there is a Smalltalk image customized for the classroom and aimed at elementary school students. That's what I'm hoping for. stepharo wrote ESUG is about the community. Without community then it is terrible. We set up also a program for teachers. Now in the US there is nearly nobody teaching smalltalk and this is a pity. -- View this message in context: http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797760.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. -- View this message in context: http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797909.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
[Pharo-dev] does anyone have a postal address for Rmod that is suitable for online delivery?
Hi, I need to send something to Rmod. Anyone got an address that shop bots accept? -- best, Eliot
Re: [Pharo-dev] does anyone have a postal address for Rmod that is suitable for online delivery?
40 avenue Halley, Bâtiment B + office number if you've got it 59650 Villeneuve d'Ascq - France At least I used that one for Amazon shippments... 2015-01-05 16:45 GMT-03:00 Eliot Miranda eliot.mira...@gmail.com: Hi, I need to send something to Rmod. Anyone got an address that shop bots accept? -- best, Eliot
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
Ah Henry but you are making the code to know if it’s a collection or not, I talking about making the code specifically to ignore that. Why that would lead to bad code? can you elaborate or put examples instead of adjectives? On Jan 5, 2015, at 1:02 PM, Henrik Johansen henrik.s.johan...@veloxit.no wrote: No, I'm talking about exactly what I quoted, implementing ifNilOrEmpty: on just UndefinedObject/Collection, but not Object. Doing that is not about indoctrinating, but preventing bad code resulting from using the same variable to hold non-polymorphic objects. Whatever the case does your idea pass this test? testIfNilOrEmpty | stuff thing | stuff := nil. self assert: stuff equals: nil. self assert: thing equals: nil. thing := stuff ifNilOrEmpty: [ 42 ]. self assert: thing equals: 42. stuff := 1984. thing := stuff ifNilOrEmpty: [ 42 ]. self deny: thing = nil. self assert: thing equals: 1984. self deny: thing = 42. Of course, since my idea was to use ifNil: when the variable you are dealing with is not Collections.
Re: [Pharo-dev] Old inspector and explorer
Hi Sebastian, As I said, I do not see how your generic advice applies to the current situation. We went through concrete cases exactly to elucidate how people perceived the problems. If things would be as obvious as removing a click, we would not have this conversation, but it is not. That is why we have to talk about concrete scenarios. In the meantime, I addressed the two points raised in the thread: - adding dynamic variables to the Raw view, and - adding collection items in the Raw view. I will follow up with more details in the following days. Cheers, Doru On Mon, Jan 5, 2015 at 3:31 PM, Sebastian Sastre sebast...@flowingconcept.com wrote: since you’re working on this I really wish you could make the links yourself to get the right inspiration. You are the right guy for that. For everybody being critical of your own work is hard but is one of the most valuable things you can have. The vulgar thing is the opposite (being defensive) and that’s the road to mediocrity. In any case, sure, I can take notes on usability and share it with you. As a start and concrete example take anything that now requires one extra click or keystroke that before was not. On Jan 5, 2015, at 12:05 PM, Tudor Girba tu...@tudorgirba.com wrote: Hi Sebastian, I really do not see how your reply applies to the case at hand. If you have a concrete remark regarding how something is less useful now, please feel free to make it. Cheers, Doru On Mon, Jan 5, 2015 at 3:00 PM, Sebastian Sastre sebast...@flowingconcept.com wrote: +1 Remember that “old” also means that it *stands the test of time* We need to be careful while innovating with the basics (workspace, inspecting, navigating code and debugging) because that impacts the whole economy of using this technology. Make productivity go up, never down! One additional click doesn’t sound like a lot but if that happens for something that you do 400 times a day is ~8000 times a month or ~60 minutes of clicking like crazy with overhead you didn’t have before. UX is King. No way back from that, it really rules (the only thing we have in control is what kingdom will we invent for it to rule) On Dec 26, 2014, at 2:42 PM, stepharo steph...@free.fr wrote: + 1 Debugging the rendering loops of Athens was such an example. In Bloc I get some race conditions with MC forked process... another fun one. Let people decide!!! Doru I DO NOT WANT TO LEARN WHAT I DO NOT WANT TO LEARN! I WANT to DECIDE WHEN. I control my agenda and my own schedule and my list is huge. Stef Doru, I think your intention is a good one but slightly misplaced. I really like the idea of GTInspector. It surely is a great tool and maybe I'll start to build my own inspector on my kind of things. To me the difference is between motivated to do or forced to do. Most of the time we are trying hard to solve our own problems. If in that progress other problems are forced upon us we get easily distracted and frustrated. The same goes for new tools. If I'm forced to use these it just means I have to deal with it first and only then I'm allowed to deal with my own problem. As it was in that special case the bug in nautilus and the new inspector made me shy away from developing something in 4.0 and now I'm back on 3.0. So I think the only possibility is to offer a new way of doing things and give people time to adjust. Norbert Am 26.12.2014 um 13:18 schrieb Tudor Girba tu...@tudorgirba.com: Hi, I think there must be a misunderstanding. There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use. There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore. What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear? But, as I said, there can still be a valid reason to enable a basic inspector that
Re: [Pharo-dev] [Moose-dev] Re: GTDebugger raising an emergency debugger
Great! Now, the Moose 5.1 image is usable on top of Pharo 4.0! There are still some red tests, but it works reasonably. It took about 1 day of work and it was mostly due to problems related with the GTDebugger (which I do not expect other projects to have ;)). Cheers, Doru On Mon, Jan 5, 2015 at 4:33 PM, Andrei Chis chisvasileand...@gmail.com wrote: Hi, I fixed the problem with the debugger. Let me know if you encounter any other problems. Cheers, Andrei On Mon, Jan 5, 2015 at 4:26 PM, Tudor Girba tu...@tudorgirba.com wrote: Yes. That one is based on Pharo 4.0 and it is not ready for consumption yet. Doru On Mon, Jan 5, 2015 at 3:08 PM, Alexandre Bergel alexandre.ber...@me.com wrote: https://ci.inria.fr/moose/job/moose-5.1/3/artifact/moose-5.1.zip https://ci.inria.fr/moose/job/moose-5.1/3/ Alexandre On Jan 5, 2015, at 10:48 AM, Tudor Girba tu...@tudorgirba.com wrote: Which job? :) Doru On Mon, Jan 5, 2015 at 2:27 PM, Alexandre Bergel alexandre.ber...@me.com wrote: I have downloaded the last version of Moose, directly from jenkins Alexandre On Jan 5, 2015, at 10:18 AM, Tudor Girba tu...@tudorgirba.com wrote: Hi, I moved most of the jobs to use Pharo 4, and indeed, we have an issue with the GTDebugger. What image are you using? Cheers, Doru On Mon, Jan 5, 2015 at 2:07 PM, Alexandre Bergel alexandre.ber...@me.com wrote: Hi! I wanted to have a look at why some tests are failing in the last version of moose. But I cannot even open a debugger. Maybe some classes are missing. I see SystemDictionaryat: in the call stack. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com Every thing has its own flow ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com Every thing has its own flow ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com Every thing has its own flow ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] On Twitter
SRP has poster children. But seriously, Pharo is the poster child. Seaside and Amber are the poster children representing the web. I'm focussed on Amber because I firmly believe that Smalltalk must have a good client-side story. The web is so important to the future of Smalltalk. Sven Van Caekenberghe-2 wrote Yes I know, and it *is* an interesting project, for sure. But my remark was in the context of The Smalltalk Renaissance - does it really fit ? Is it the best poster child ? -- View this message in context: http://forum.world.st/On-Twitter-tp4797177p4797863.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] The Smalltalk Renaissance Program
Thanks! I had never heard of Phratch (or Scratch, for that matter). It looks very promising. I can imagine it's sorta like LEGO in Smalltalk. What youngster wouldn't like that? Ben Coman wrote Maybe Phratch? Then maybe they start looking under the hood? http://www.phratch.com/ On Mon, Jan 5, 2015 at 10:31 PM, horrido lt; horrido.hobbies@ gt; wrote: Oh, I didn't realize you were focussed on older kids. I'm looking at introducing Smalltalk at the elementary school level, getting kids hooked on Smalltalk at an early age. Probably a full-blown Pharo or Squeak image would be overkill. stepharo wrote It depends what is the level you are looking for. We are working on lectures and books for second and third year university students. Now for kids I do not think that it matters if this the language or software is writting in Smalltalk. Stef Le 4/1/15 23:25, horrido a écrit : I am intrigued. Where can I find more info about Smalltalk education in the schools? I want to see what I can do in Canada. I presume there is a Smalltalk image customized for the classroom and aimed at elementary school students. That's what I'm hoping for. stepharo wrote ESUG is about the community. Without community then it is terrible. We set up also a program for teachers. Now in the US there is nearly nobody teaching smalltalk and this is a pity. -- View this message in context: http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797760.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. -- View this message in context: http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797846.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. -- View this message in context: http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797868.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
On Jan 5, 2015, at 1:48 PM, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 05 Jan 2015, at 4:20 , Sebastian Sastre sebast...@flowingconcept.com mailto:sebast...@flowingconcept.com wrote: Ah Henry but you are making the code to know if it’s a collection or not, I talking about making the code specifically to ignore that. Why that would lead to bad code? can you elaborate or put examples instead of adjectives? I did that already: I took a look at the thread and I don’t see examples of bad code I’m still curious about what you mean by that
Re: [Pharo-dev] On Twitter
On 05 Jan 2015, at 16:09, p...@highoctane.be wrote: On Mon, Jan 5, 2015 at 3:57 PM, Sven Van Caekenberghe s...@stfx.eu wrote: On 05 Jan 2015, at 15:28, horrido horrido.hobb...@gmail.com wrote: You're quite right. I guess I should focus on *one thing* right now before it gets lost in the shuffle: Complete and publish my Amber tutorial. I have a lot of work ahead of me in this one. Not that I have anything against Amber, but why pick that one ? Everybody seems to think something along the lines of 'JavaScript is very popular, if only we get on that platform and we'll be all set' - I don't think that is the case. Even Amber's original developer is now working full time on JavaScript, yet does no longer seem to use it. Hey, Amber is alive! 0.14 just out. Herby does a good job, examples are refined, we are injecting effort in it. Yes I know, and it *is* an interesting project, for sure. But my remark was in the context of The Smalltalk Renaissance - does it really fit ? Is it the best poster child ? It takes a while to get things to 1.0. We can't afford to pass on SPAs and it is not with Seaside that we'll do it. Also, on technical grounds it could be argued that Amber misses a number of critical Smalltalk features (thisContext, #become:). Furthermore, it is slower and has a only a limited IDE. thisContext and become: aren't in but even like that, the prototyping power of Amber is strong even if tooling can be improved (first the core, then the bells and whistles). Javascript also has features that Smalltalk doesn't have. So, it is a give or take game. If anything, Amber helps one into understanding the current Javascript ways in a quite good manner. It does for me. Other than that, focus is good. For the time being, I'll cut back on my tweets and Facebook and Google+.
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
I see , very interesting I will definitely take a look because obviously this something I want to use too . On Mon, Jan 5, 2015 at 3:44 PM, p...@highoctane.be p...@highoctane.be wrote: Exception handling is used a lot. Check senders of #on:do: 457 in my Pharo 3.0 That's not counting the 303 #ensure: that are used transparently in things like: aFileRef readStreamDo: [ :s | s upToEnd ] Phil On Mon, Jan 5, 2015 at 2:12 PM, kilon alios kilon.al...@gmail.com wrote: I dont know javascript well nor pharo but I am coming from python and for this scenario it would make more sense to me to use an exception than an actual check. At least that is the way Python deals with this situation which is an approach I really like. I know Pharo has exception handling as well, but unlike Python where exception handling is very popular I have barely seen it used by pharo coders. I am curious why . On Mon, Jan 5, 2015 at 3:01 PM, Sebastian Sastre sebast...@flowingconcept.com wrote: On Jan 5, 2015, at 10:38 AM, p...@highoctane.be wrote: In business apps, the need for default values happen all the time, so the idiom has value (not sure for the message name though). Totally. In real apps, having to compare against uninitialized variable or nil as response or empty string happens so often that having this method makes it quite convenient (AKA lots of code becomes one-liners). We could use x := [ self thing ] ifError: [ someDefault ] I understand you’re setting a similar, quite not like it example but in any case this one raises and catches an exception and that sounds quite less efficient if compared to return self (when object is not nil and is not an empty collection/string) for these purposes. Triggering errors is not too nice still. Now, what if self itself is nil or empty? BTW, isEmptyOrNil exists in the image for Collections and UndefinedObject. Empty has no meaning for Object, so why test against empty in the name? Note that is not a testing method, it’s a conditional executor of the closure. The reason why was already mentioned, is to allow you to write this one-liner convenience: someVar := self thing ifNilOrEmpty: [blah] `self thing` could be an expensive process that returns something or nil or an empty collection. *If* you get nil or empty as result then you would get the block values resulting in having blah at someVar In the image, I see that we do have #default: anObject in several places. It seems to serve the same intent. What is the idiom for such things in Pharo? Importing idioms from other languages works but if we do have one already, we will introduce confusion. how can you do that one-liner without introducing *ifNilOrEmpty:* ? Phil On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba tu...@tudorgirba.com wrote: This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection. A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty. Cheers, Doru On Mon, Jan 5, 2015 at 1:17 PM, Sebastian Sastre sebast...@flowingconcept.com wrote: taste is taste but would you care to illustrate your point with examples? I’m curious about it On Jan 5, 2015, at 6:12 AM, stepharo steph...@free.fr wrote: You summarise well the kind of code I do not like. isNil everywhere and horrible tests. Stef Le 4/1/15 23:27, Sebastian Sastre a écrit : Hi guys, I’ve started to use this little one: ObjectifNilOrEmpty: aBlock self ifNil: [ ^ aBlock value ]. (self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ]. ^ self. It allows you to do the widely known JavaScript one-liner: var stuff = this.thing || ‘some default value for when this.thing is undefined, null or an empty string’. but in smalltalk in this way: stuff := self thing ifNilOrEmpty: [ ‘some default value for when self thing is nil or an empty string’ ] simple thing feels practical and nice :) -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
On 05 Jan 2015, at 4:20 , Sebastian Sastre sebast...@flowingconcept.com wrote: Ah Henry but you are making the code to know if it’s a collection or not, I talking about making the code specifically to ignore that. Why that would lead to bad code? can you elaborate or put examples instead of adjectives? I did that already: On 05 Jan 2015, at 3:07 , Henrik Johansen henrik.s.johan...@veloxit.no wrote: it will lead to are you a collection or single instance? checks in almost every user of said variable. Cheers, Henry
Re: [Pharo-dev] [Bulk] [Bulk] Can MongoTalk execute plan javascript MongoDB queries?
Hi Norbert,
this reminds me of something IIRC that Alan Knight did in TopLink, a
commercial OR mapping tool. Alan allowed one to write queries in conventional
Smalltalk such as
db select: [:obj| obj name = 'foo' or: [obj feature isSomething]]
but under the covers compiling this block into a query that the database could
execute by evaluating the block once, passing in a compiling object that
implements doesNotUnderstand: to catch the messages sent in the block.
That technique could work in this context and avoid introducing the (excuse me
for saying, /horrible/) tuple syntax.
Eliot (phone)
On Jan 5, 2015, at 4:41 AM, Norbert Hartl norb...@hartl.name wrote:
Am 05.01.2015 um 04:59 schrieb Yanni Chiu ya...@rogers.com:
On Jan 4, 2015, at 4:38 AM, Norbert Hartl norb...@hartl.name wrote:
someCollection select: {
'$or' - {
{ 'name' - {
'$regex' - 'test' .
'$options' - 'i' } asDictionary } asDictionary.
{ 'description' - {
'$regex' - 'test' .
'$options' - 'i' } asDictionary } asDictionary
}
} asDictionary
That worked. I was close, but I was using $or: instead of $or, and I was
missing one level of asDictionary.
Just for the archive, there’s one more query I needed, which was to find an
object based on it’s object id. I ended up using:
voyageId := Integer readFrom: (request at: #voyageId) base: 16.
someModel := SomeModel selectOne: { '_id' - (OID value: voyageId) }
asDictionary.
This is a web app using Teapot and Mustache, so I write the voyageId out
using:
self voyageId value printStringHex
Sounds cool. If you have anything to publish I'm interested what you've done.
Especially if you have some nice tricks doing form handling in teapot.
Btw. for the archive. A common use case I encounter is to query objects that
are being referenced by another object. It works like this
AnyClass#referencedBy: anObject
^ AnyClass selectMany: {
'reference.__id' - anObject voyageId } asDictionary
Norbert
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
Am 05.01.2015 um 15:22 schrieb Sebastian Sastre sebast...@flowingconcept.com: On Jan 5, 2015, at 12:00 PM, Norbert Hartl norb...@hartl.name mailto:norb...@hartl.name wrote: Am 05.01.2015 um 14:43 schrieb Sebastian Sastre sebast...@flowingconcept.com mailto:sebast...@flowingconcept.com: one hugely typical case is having the model of an input that has either nil because is pristine or an empty string and the app needs to guarantee some default value that should not be nil or an empty string. Another frequent case is the response of some API that will typically answer nil or an empty collection when something is not found and you want to guarantee some value or model that should not be nil or an empty collection. About #thing being meaningless, sure, I’ve mentioned as general example. I don’t see that every user of #thing has to use the ifNilOrEmpty:, only those who care about guaranteeing that closure valued if none is found which is expressed in the completely sensible form of receiving nil or an empty collection :) My point is that as long as you do not promise a certain type of object you will have to deal with the uncertainty what methods you can call on that object of uncertain type. By not using a check you just extend the life of this uncertainty a while longer (bad if the user of your code has to deal with it). Some has to deal with it if the object has to do something. And the earlier this uncertainty is removed the better it is. At least in my opinion. Norbert Ah! I understand your point better now, thanks for clarifying. Actually you helped me to understand better something I systematically do often which is extending that uncertainty as much as is convenient :) For example Mapless http://sebastianconcept.github.io/Mapless (and MiniMapless https://github.com/flow-stack/MiniMapless) gives you the freedom of not having to predict what instance variables your persistent objects will have and still gives you the features now. Is the opposite of the predictive certainty demanded by typed technologies and their the compiler is your friend BS that completely frustrates your creative flow. Dynamic technologies are all about delaying certainty. Late binding is delaying it until runtime. I don’t say this as a technicality, I see it as a useful tool to push the present into the future and pull the future into the present. I think I need to be more clear on this. With type I meant a set of methods I can call on an object. You can name it protocol or interface or duck type. With certainty I meant that a method #thing has to give a promise about a certain type (it returns) so you know what you can call on that object. Without knowing the type you can only invoke the set of methods defined in Object or you can use objects as structs. To build objects that serve a specific purpose you need to establish communication ways (methods and calls) that exceed that. It's all about communication after all. So I would say you need to establish certainty at coding time (using interfaces and objects). Late binding postpones the specific implementation of your type that make it possible to have plenty of use cases managed. Norbert Being able to reflect in real-time makes this possible. Is what makes easier to invent the future when they “touch each other. If someone else has to deal with the object and code with this uncertainty, you know you’re on the right place for personal mastery http://www.cs.virginia.edu/~cs655/readings/smalltalk.html to happen since Smalltalk was designed to allow the individual to easily navigate code and master the system by itself. This is actually a major reason to choose Smalltalk. Thanks again!
Re: [Pharo-dev] Old inspector and explorer
I agree completely , Dorus has been a very good listener to criticism and he has changed things on popular request. Asking for concrete examples instead of falling down the trap of discussing general philosophies and ideologies is the way to go. On Mon, Jan 5, 2015 at 4:59 PM, Sven Van Caekenberghe s...@stfx.eu wrote: On 05 Jan 2015, at 15:31, Sebastian Sastre sebast...@flowingconcept.com wrote: since you’re working on this I really wish you could make the links yourself to get the right inspiration. You are the right guy for that. For everybody being critical of your own work is hard but is one of the most valuable things you can have. The vulgar thing is the opposite (being defensive) and that’s the road to mediocrity. In any case, sure, I can take notes on usability and share it with you. As a start and concrete example take anything that now requires one extra click or keystroke that before was not. Doru is anything but defensive. He literally asks for concrete examples. The goal is to make the workflow better for everyone. On Jan 5, 2015, at 12:05 PM, Tudor Girba tu...@tudorgirba.com wrote: Hi Sebastian, I really do not see how your reply applies to the case at hand. If you have a concrete remark regarding how something is less useful now, please feel free to make it. Cheers, Doru On Mon, Jan 5, 2015 at 3:00 PM, Sebastian Sastre sebast...@flowingconcept.com wrote: +1 Remember that “old” also means that it stands the test of time We need to be careful while innovating with the basics (workspace, inspecting, navigating code and debugging) because that impacts the whole economy of using this technology. Make productivity go up, never down! One additional click doesn’t sound like a lot but if that happens for something that you do 400 times a day is ~8000 times a month or ~60 minutes of clicking like crazy with overhead you didn’t have before. UX is King. No way back from that, it really rules (the only thing we have in control is what kingdom will we invent for it to rule) On Dec 26, 2014, at 2:42 PM, stepharo steph...@free.fr wrote: + 1 Debugging the rendering loops of Athens was such an example. In Bloc I get some race conditions with MC forked process... another fun one. Let people decide!!! Doru I DO NOT WANT TO LEARN WHAT I DO NOT WANT TO LEARN! I WANT to DECIDE WHEN. I control my agenda and my own schedule and my list is huge. Stef Doru, I think your intention is a good one but slightly misplaced. I really like the idea of GTInspector. It surely is a great tool and maybe I'll start to build my own inspector on my kind of things. To me the difference is between motivated to do or forced to do. Most of the time we are trying hard to solve our own problems. If in that progress other problems are forced upon us we get easily distracted and frustrated. The same goes for new tools. If I'm forced to use these it just means I have to deal with it first and only then I'm allowed to deal with my own problem. As it was in that special case the bug in nautilus and the new inspector made me shy away from developing something in 4.0 and now I'm back on 3.0. So I think the only possibility is to offer a new way of doing things and give people time to adjust. Norbert Am 26.12.2014 um 13:18 schrieb Tudor Girba tu...@tudorgirba.com: Hi, I think there must be a misunderstanding. There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use. There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore. What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear? But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for
Re: [Pharo-dev] Old inspector and explorer
Sure Doru, as said, I’ll share usability notes with you, we will talk about concrete cases and they are going to be aligned with my non-off-topic general reminder :) Thanks again for all the effort you are putting on this On Jan 5, 2015, at 1:28 PM, Tudor Girba tu...@tudorgirba.com wrote: Hi Sebastian, As I said, I do not see how your generic advice applies to the current situation. We went through concrete cases exactly to elucidate how people perceived the problems. If things would be as obvious as removing a click, we would not have this conversation, but it is not. That is why we have to talk about concrete scenarios. In the meantime, I addressed the two points raised in the thread: - adding dynamic variables to the Raw view, and - adding collection items in the Raw view. I will follow up with more details in the following days. Cheers, Doru On Mon, Jan 5, 2015 at 3:31 PM, Sebastian Sastre sebast...@flowingconcept.com mailto:sebast...@flowingconcept.com wrote: since you’re working on this I really wish you could make the links yourself to get the right inspiration. You are the right guy for that. For everybody being critical of your own work is hard but is one of the most valuable things you can have. The vulgar thing is the opposite (being defensive) and that’s the road to mediocrity. In any case, sure, I can take notes on usability and share it with you. As a start and concrete example take anything that now requires one extra click or keystroke that before was not. On Jan 5, 2015, at 12:05 PM, Tudor Girba tu...@tudorgirba.com mailto:tu...@tudorgirba.com wrote: Hi Sebastian, I really do not see how your reply applies to the case at hand. If you have a concrete remark regarding how something is less useful now, please feel free to make it. Cheers, Doru On Mon, Jan 5, 2015 at 3:00 PM, Sebastian Sastre sebast...@flowingconcept.com mailto:sebast...@flowingconcept.com wrote: +1 Remember that “old” also means that it stands the test of time We need to be careful while innovating with the basics (workspace, inspecting, navigating code and debugging) because that impacts the whole economy of using this technology. Make productivity go up, never down! One additional click doesn’t sound like a lot but if that happens for something that you do 400 times a day is ~8000 times a month or ~60 minutes of clicking like crazy with overhead you didn’t have before. UX is King. No way back from that, it really rules (the only thing we have in control is what kingdom will we invent for it to rule) On Dec 26, 2014, at 2:42 PM, stepharo steph...@free.fr mailto:steph...@free.fr wrote: + 1 Debugging the rendering loops of Athens was such an example. In Bloc I get some race conditions with MC forked process... another fun one. Let people decide!!! Doru I DO NOT WANT TO LEARN WHAT I DO NOT WANT TO LEARN! I WANT to DECIDE WHEN. I control my agenda and my own schedule and my list is huge. Stef Doru, I think your intention is a good one but slightly misplaced. I really like the idea of GTInspector. It surely is a great tool and maybe I'll start to build my own inspector on my kind of things. To me the difference is between motivated to do or forced to do. Most of the time we are trying hard to solve our own problems. If in that progress other problems are forced upon us we get easily distracted and frustrated. The same goes for new tools. If I'm forced to use these it just means I have to deal with it first and only then I'm allowed to deal with my own problem. As it was in that special case the bug in nautilus and the new inspector made me shy away from developing something in 4.0 and now I'm back on 3.0. So I think the only possibility is to offer a new way of doing things and give people time to adjust. Norbert Am 26.12.2014 um 13:18 schrieb Tudor Girba tu...@tudorgirba.com mailto:tu...@tudorgirba.com: Hi, I think there must be a misunderstanding. There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use. There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore. What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take
Re: [Pharo-dev] On Twitter
Just wondering, did you actually see this page: http://pharo.org/success ? This is all real, commercially successful stuff. Not that we don't need more traction, but it is important to understand and know what is already there. On 05 Jan 2015, at 16:41, horrido horrido.hobb...@gmail.com wrote: SRP has poster children. But seriously, Pharo is the poster child. Seaside and Amber are the poster children representing the web. I'm focussed on Amber because I firmly believe that Smalltalk must have a good client-side story. The web is so important to the future of Smalltalk. Sven Van Caekenberghe-2 wrote Yes I know, and it *is* an interesting project, for sure. But my remark was in the context of The Smalltalk Renaissance - does it really fit ? Is it the best poster child ? -- View this message in context: http://forum.world.st/On-Twitter-tp4797177p4797863.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] On Twitter
On Jan 5, 2015, at 2:02 PM, Sven Van Caekenberghe s...@stfx.eu wrote: Just wondering, did you actually see this page: http://pharo.org/success http://pharo.org/success ? This is all real, commercially successful stuff. Not that we don't need more traction, but it is important to understand and know what is already there. +1 That’s a good starting point Richard. Idea: if you interview the people beyond those cases it will make everything more interesting for everybody
Re: [Pharo-dev] does anyone have a postal address for Rmod that is suitable for online delivery?
Hi eliot Put Inria - Rmod 40 av de Halley, Parc de la Haute Borne, 59650 Villeneuve d'Ascq - France Le 5/1/15 20:45, Eliot Miranda a écrit : Hi, I need to send something to Rmod. Anyone got an address that shop bots accept? -- best, Eliot
Re: [Pharo-dev] ObjectifNilOrEmpty: aBlock
Esteban, Go rest your brain cells... Vacations are always too short! Phil On Mon, Jan 5, 2015 at 9:35 PM, Esteban Lorenzano esteba...@gmail.com wrote: probably, but in any case it has to be implemented using existing idioms, not repeating code, which was the core of my point. crap. I really need to turn off my computer or I will continue watching mails ;) Esteban On 05 Jan 2015, at 17:25, Tudor Girba tu...@tudorgirba.com wrote: Hi, As discussed in this thread, I do not see a reason for implementing this method in Object. Having it in Collection/UndefinedObject can make some sense (although I do not really like it) for working with variables that can be either collection or nil. Cheers, Doru On Mon, Jan 5, 2015 at 8:59 PM, Esteban Lorenzano esteba...@gmail.com wrote: in any case, we already have the idiom #isEmptyOrNil (btw, in pharo4 it was removed from Object and I don’t know why, but is still in Collection and in UndefinedObject). So, in case of adding it, the correct implementation should be: 1) restore Object#isEmptyOrNil ^ false 2) implement: Object#ifEmptyOrNil: aBlock self isEmptyOrNil ifTrue: aBlock. ^ self which IMO is the clean way to implement such idiom. said that, I will go back to my vacations :) Esteban On 05 Jan 2015, at 15:47, Esteban A. Maringolo emaring...@gmail.com wrote: El Mon Jan 05 2015 at 3:36:50 PM, stepharo steph...@free.fr escribió: This is not because some people may not know how to program in other languages that we should copy that. I share your taste for this kind of code. But this purist approach raises the bar leaving out a lot of developers with poor design/modelling skills. The more 1:1 mappings they can bring in from their previous language of choice, the better, and higher the odds they'll clinge on Pharo and continue using it. To make both sides of this discussion happy I think the base image shouldn't include this, and there can be an extra package with these language extensions. Regards! -- www.tudorgirba.com Every thing has its own flow
