From sandor.szuecs at fu-berlin.de Sun Feb 1 13:07:00 2009 From: sandor.szuecs at fu-berlin.de (=?ISO-8859-1?Q?Sandor_Sz=FCcs?=) Date: Sun, 1 Feb 2009 19:07:00 +0100 Subject: [Facets] introduce myself, git and first push Message-ID: <21BE509C-D57E-4054-A916-1828E3336118@fu-berlin.de> Hi! I just want to introduce myself on the list. I was added to the project by Trans, after I sent him patches. My primary goal is to push facets to ruby19. I also want to fix outstanding bugs and add testcases for them. If there are design issues I will post them here and hope we can discuss it. I have problems with pushing to rubyforge, for now I created a fork on github [1]. I don't really know, but maybe it's the right use case of git. Git is decentralized and maybe it's the way to use!? If you have hints howto use git in a project with more then one member then drop me an e-mail. My first push include: - product.rb change was discussed with Trans: delete the block argument - test_local_variables.rb: ruby19 use symbols instead of strings in general, so return symbols is ok on 19 I just pushed it now to [1]. [1] http://github.com/szuecs/facets/tree/master Regards, Sandor Sz?cs -- From sandor.szuecs at fu-berlin.de Mon Feb 2 12:09:33 2009 From: sandor.szuecs at fu-berlin.de (=?ISO-8859-1?Q?Sandor_Sz=FCcs?=) Date: Mon, 2 Feb 2009 18:09:33 +0100 Subject: [Facets] Upcoming Release In-Reply-To: References: Message-ID: <3719F602-D459-4B69-A196-FAC843297B7A@fu-berlin.de> On 01.02.2009, at 01:07, Trans wrote: > Unless something comes up I will most likely release Facets 2.5.1 here > in the next week. This is primarily a bug fix release, and mostly for > working with 1.9 at that. > > If anyone has any other issues addressed before the next release, > please let me know soon. I pushed two little changes to the repo on rubyforge. As we discussed I removed the block parameter of array/product.rb, changed the test according that change and fixed the test core/binding/test_local_variables.rb according the ruby19 standard. (1.8 uses String, 1.9 use Symbol) My problems with git and rubyforge are gone, after I used the right repository. .oO(*plonk*) Regards, Sandor Sz?cs -- From sandor.szuecs at fu-berlin.de Mon Feb 2 12:30:37 2009 From: sandor.szuecs at fu-berlin.de (=?ISO-8859-1?Q?Sandor_Sz=FCcs?=) Date: Mon, 2 Feb 2009 18:30:37 +0100 Subject: [Facets] Upcoming Release In-Reply-To: References: Message-ID: <6933AB0E-94AB-43F0-8454-2A27E09E0BB7@fu-berlin.de> On 01.02.2009, at 01:07, Trans wrote: > Unless something comes up I will most likely release Facets 2.5.1 here > in the next week. This is primarily a bug fix release, and mostly for > working with 1.9 at that. > > If anyone has any other issues addressed before the next release, > please let me know soon. I also fixed a bug in Array#to_hash, h was not initialized. regards, Sandor Sz?cs -- From transfire at gmail.com Mon Feb 2 12:37:28 2009 From: transfire at gmail.com (Trans) Date: Mon, 2 Feb 2009 09:37:28 -0800 (PST) Subject: [Facets] introduce myself, git and first push In-Reply-To: <21BE509C-D57E-4054-A916-1828E3336118@fu-berlin.de> References: <21BE509C-D57E-4054-A916-1828E3336118@fu-berlin.de> Message-ID: <606aeb8b-caa2-41ff-85de-c3c1811e9b28@y1g2000pra.googlegroups.com> On Feb 1, 1:07?pm, Sandor Sz?cs wrote: > Hi! > > I just want to introduce myself on the list. > I was added to the project by Trans, after I sent him patches. > My primary goal is to push facets to ruby19. > I also want to fix outstanding bugs and add testcases for them. > If there are design issues I will post them here and hope we can > discuss it. > > I have problems with pushing to rubyforge, for now I created a fork > on github [1]. I don't really know, but maybe it's the right use case > of git. Git is decentralized and maybe it's the way to use!? > If you have hints howto use git in a project with more then one > member then drop me an e-mail. > > My first push include: > - product.rb change was discussed with Trans: delete the block argument > - test_local_variables.rb: ruby19 use symbols instead of strings in ? > general, so return symbols is ok on 19 > > I just pushed it now to [1]. > > [1]http://github.com/szuecs/facets/tree/master Hey Sandor. I've meaning to put the repo on GitHub too. What is the link to the one you put up? Maybe we can just work off that one? Or should I put up an "offical" master repo? I'm not sure how Github works with that --I want to use the wiki feature, so I'm thinking there has to be "master" repo to do that. I still want to keep the Rubyforge repo in sync though --that will be the real master repo actually. I can keep the two in sync for now, but we will have to figure out why your push to Rubyforge is still not working at some point. Also, to date not much discussion has occurred here. Most discussion has been via Rubyforge Tracker and/or personal email. But I'd would like to see that change, so I am very glad you made this post. T. From transfire at gmail.com Mon Feb 2 12:41:33 2009 From: transfire at gmail.com (Trans) Date: Mon, 2 Feb 2009 09:41:33 -0800 (PST) Subject: [Facets] Upcoming Release In-Reply-To: <3719F602-D459-4B69-A196-FAC843297B7A@fu-berlin.de> References: <3719F602-D459-4B69-A196-FAC843297B7A@fu-berlin.de> Message-ID: On Feb 2, 12:09?pm, Sandor Sz?cs wrote: > On 01.02.2009, at 01:07, Trans wrote: > > > Unless something comes up I will most likely release Facets 2.5.1 here > > in the next week. This is primarily a bug fix release, and mostly for > > working with 1.9 at that. > > > If anyone has any other issues addressed before the next release, > > please let me know soon. > > I pushed two little changes to the repo on rubyforge. > As we discussed I removed the block parameter of array/product.rb, > changed the test according that change and fixed the test > core/binding/test_local_variables.rb according the ruby19 standard. > (1.8 uses String, 1.9 use Symbol) > > My problems with git and rubyforge are gone, after I used the right > repository. .oO(*plonk*) Excellent News! T. From sandor.szuecs at fu-berlin.de Mon Feb 2 16:26:17 2009 From: sandor.szuecs at fu-berlin.de (=?ISO-8859-1?Q?Sandor_Sz=FCcs?=) Date: Mon, 2 Feb 2009 22:26:17 +0100 Subject: [Facets] introduce myself, git and first push In-Reply-To: <606aeb8b-caa2-41ff-85de-c3c1811e9b28@y1g2000pra.googlegroups.com> References: <21BE509C-D57E-4054-A916-1828E3336118@fu-berlin.de> <606aeb8b-caa2-41ff-85de-c3c1811e9b28@y1g2000pra.googlegroups.com> Message-ID: <6CC6AACC-6846-4370-8E59-933D0018392D@fu-berlin.de> On 02.02.2009, at 18:37, Trans wrote: > > On Feb 1, 1:07 pm, Sandor Sz?cs wrote: >> I just pushed it now to [1]. >> >> [1]http://github.com/szuecs/facets/tree/master > > Hey Sandor. I've meaning to put the repo on GitHub too. What is the > link to the one you put up? You don't have to merge it, I already added the changes to the rubyforge repo. Mine is git://github.com/szuecs/facets.git But it's a fork of http://github.com/smtlaissezfaire/facets/tree aka git://github.com/smtlaissezfaire/facets.git. That one is from Scott Taylor, which I include in Cc. I just realized that it wasn't the original. Maybe Scott can tell us how to do it right. He has more experience with github. > Maybe we can just work off that one? Or > should I put up an "offical" master repo? I think you should create a second facets repo on github. The master repo should be the rubyforge one. > I'm not sure how Github > works with that --I want to use the wiki feature, so I'm thinking > there has to be "master" repo to do that. I don't know github very well it's new for me. > I still want to keep the > Rubyforge repo in sync though --that will be the real master repo > actually. Yes we can just push to both. Create an account on github. Then we can add a second repository address on .git/config and we just push on both, as Dr.Nic mentioned [2]. Create a shell function and we simply use both. Maybe a rake task is a better solution, so nobody can forget to push it to both repositories. [2] http://drnicwilliams.com/2008/04/08/git-for-rubyforge-accounts/ > I can keep the two in sync for now, but we will have to > figure out why your push to Rubyforge is still not working at some > point. I realized that I did a failure, I cloned the public repository and on public I was not allowed to push to rubyforge. Now I use the right uri and it works, I pushed already my changes. You should see it if you `git log' or if not then you have to `git pull', I think. > Also, to date not much discussion has occurred here. Most discussion > has been via Rubyforge Tracker and/or personal email. But I'd would > like to see that change, so I am very glad you made this post. ack. Here is the right place to discuss. Maybe you should point from everywhere to the group here, and not to your e-mail address. OT: On http://facets.rubyforge.org/community.xml you have posted your e-mail adress but there is a 'd' instead of a 's' (trandfire...). Regards, Sandor Sz?cs -- From transfire at gmail.com Tue Feb 3 14:51:36 2009 From: transfire at gmail.com (Trans) Date: Tue, 3 Feb 2009 11:51:36 -0800 (PST) Subject: [Facets] introduce myself, git and first push In-Reply-To: <6CC6AACC-6846-4370-8E59-933D0018392D@fu-berlin.de> References: <21BE509C-D57E-4054-A916-1828E3336118@fu-berlin.de> <606aeb8b-caa2-41ff-85de-c3c1811e9b28@y1g2000pra.googlegroups.com> <6CC6AACC-6846-4370-8E59-933D0018392D@fu-berlin.de> Message-ID: <3c162f60-1a44-4ef3-afd9-82b0bd09eb14@m16g2000vbp.googlegroups.com> On Feb 2, 4:26?pm, Sandor Sz?cs wrote: > On 02.02.2009, at 18:37, Trans wrote: > > > > > On Feb 1, 1:07 pm, Sandor Sz?cs wrote: > >> I just pushed it now to [1]. > > >> [1]http://github.com/szuecs/facets/tree/master > > > Hey Sandor. I've meaning to put the repo on GitHub too. What is the > > link to the one you put up? > > You don't have to merge it, I already added the changes to the > rubyforge repo. Cool. Be sure to pull the master repo. I just might a modification to product.rb. > Mine is git://github.com/szuecs/facets.git > But it's a fork ofhttp://github.com/smtlaissezfaire/facets/tree > aka git://github.com/smtlaissezfaire/facets.git. > That one is from Scott Taylor, which I include in Cc. I just > realized that it wasn't the original. Maybe Scott can tell us how to > do it right. He has more experience with github. > > > Maybe we can just work off that one? Or > > should I put up an "offical" master repo? > > I think you should create a second facets repo on github. The master > repo should be the rubyforge one. Okay. I have one. This will be the my development branch. http://github.com/trans/facets/tree/master It will basically stay in sync with the master (rubyforge) branch. > > I'm not sure how Github > > works with that --I want to use the wiki feature, so I'm thinking > > there has to be "master" repo to do that. > > I don't know github very well it's new for me. However it works the official Wiki is now here: http://wiki.github.com/trans/facets > Yes we can just push to both. Create an account on github. Then we > can add a second repository address on .git/config and we just push > on both, as Dr.Nic mentioned [2]. Create a shell function and we > simply use both. Maybe a rake task is a better solution, so nobody > can forget to push it to both repositories. > > [2]http://drnicwilliams.com/2008/04/08/git-for-rubyforge-accounts/ Right. I need to do that. I add a remote called 'github', and I'm using 'origin' for rubyforge. > I realized that I did a failure, I cloned the public repository and > on public I was not allowed to push to rubyforge. > Now I use the right uri and it works, I pushed already my changes. > You should see it if you `git log' or if not then you have to > `git pull', I think. I see. I'm having problems with 'git pull' actually. I have to 'git fetch origin' and then 'git merge origin/master'. Not sure why. > > Also, to date not much discussion has occurred here. Most discussion > > has been via Rubyforge Tracker and/or personal email. But I'd would > > like to see that change, so I am very glad you made this post. > > ack. Here is the right place to discuss. Maybe you should point from > everywhere to the group here, and not to your e-mail address. Good point. > OT: > Onhttp://facets.rubyforge.org/community.xmlyou have posted your > e-mail adress but there is a 'd' instead of a 's' (trandfire...). Yes I recently fixed but haven't uploaded yet. But now I think I will remove it and put the mailing list only. T. From transfire at gmail.com Tue Feb 3 14:59:59 2009 From: transfire at gmail.com (Trans) Date: Tue, 3 Feb 2009 11:59:59 -0800 (PST) Subject: [Facets] monkey patching #extend Message-ID: <5eb68d68-2c33-46e8-b275-13d249ca363e@v15g2000vbb.googlegroups.com> General policy in Facet's is not to monkey patch --that is to say, we don't override built-in methods, rather we just add new ones. There is only one or two exceptions to this rule in all of Facets. But I am thinking of adding another. I'd like to allow #extend to take a block. If provided it would create an anonymous module and extend the receiver with it. Basically (this is pseudo-code): def extend(mod, &blk) if blk super Module.new(&blk) else super end end Does anyone have any substantial objections to this idea? I do not suggest it lightly. Monkey patching is always a big deal, but it seems to me this is the right way to do this (rather than trying to come up with some other name for yet another method). T. From transfire at gmail.com Tue Feb 3 21:42:08 2009 From: transfire at gmail.com (Trans) Date: Tue, 3 Feb 2009 18:42:08 -0800 (PST) Subject: [Facets] monkey patching #extend In-Reply-To: <5eb68d68-2c33-46e8-b275-13d249ca363e@v15g2000vbb.googlegroups.com> References: <5eb68d68-2c33-46e8-b275-13d249ca363e@v15g2000vbb.googlegroups.com> Message-ID: <1f86eab6-1fc4-4322-ad88-8bb297129bb1@m15g2000vbl.googlegroups.com> On Feb 3, 2:59?pm, Trans wrote: > General policy in Facet's is not to monkey patch --that is to say, we > don't override built-in methods, rather we just add new ones. There is > only one or two exceptions to this rule in all of Facets. But I am > thinking of adding another. > > I'd like to allow #extend to take a block. If provided it would create > an anonymous module and extend the receiver with it. Basically (this > is pseudo-code): > > ? def extend(mod, &blk) > ? ? if blk > ? ? ? super Module.new(&blk) > ? ? else > ? ? ? super > ? ? end > ? end > > Does anyone have any substantial objections to this idea? I do not > suggest it lightly. Monkey patching is always a big deal, but it seems > to me this is the right way to do this (rather than trying to come up > with some other name for yet another method). Ok. I pushed this change. T. From transfire at gmail.com Thu Feb 5 14:57:03 2009 From: transfire at gmail.com (Trans) Date: Thu, 5 Feb 2009 11:57:03 -0800 (PST) Subject: [Facets] Array#to_h Message-ID: <5e430322-0df0-4581-9cbb-b0342fb71e73@w39g2000prb.googlegroups.com> I have concluded that the current implementation of Array#to_h is not consistent enough. It will convert an associative array to a hash as it is supposed to, but it will also convert an array using the equivalent of Hash[*flatten] in certain cases that are not well enough defined. So I've been thinking of using this instead: # Converts an associative array into a hash. # # a = [ [:a,1], [:b,2] ] # a.to_h #=> { :a=>1, :b=>2 } # # When a non-standard associative array is used, # the result is as follows: # # a = [ [:a,1,2], [:b,2], [:c], :d ] # a.to_h #=> { :a=>[1,2], :b=>2, :c=>nil, :d=>nil } # # If the fist entry of two or more values is the same, then # they will be joined using #concat. # # a = [ [:a,1,2], [:a,2], [:a,7], :a ] # a.to_h #=> { :a=>[1,2,2,7,nil] } # # If +arrayed+ is set it will maintain trailing arrays regardless. # # a = [ [:a,1,2], [:b,3], :c ] # a.to_h(true) #=> { :a=>[1,2], :b=>[3], :c=>[] } def to_h(arrayed=nil) h = {} each do |k,*v| h[k] ||= [] h[k].concat(v) end unless arrayed h.each do |k,v| if v.size < 2 h[k] = v[0] end end end h end This means an array like [1,2,3,4] cannot use #to_h to convert to a hash, but must use Hash[*array] instead. Thoughts? T. From sandor.szuecs at fu-berlin.de Thu Feb 5 16:44:19 2009 From: sandor.szuecs at fu-berlin.de (=?ISO-8859-1?Q?Sandor_Sz=FCcs?=) Date: Thu, 5 Feb 2009 22:44:19 +0100 Subject: [Facets] Array#to_h In-Reply-To: <5e430322-0df0-4581-9cbb-b0342fb71e73@w39g2000prb.googlegroups.com> References: <5e430322-0df0-4581-9cbb-b0342fb71e73@w39g2000prb.googlegroups.com> Message-ID: <784EBA66-1124-4A2A-BD67-F5CB2F951F8F@fu-berlin.de> On 05.02.2009, at 20:57, Trans wrote: > I have concluded that the current implementation of Array#to_h is not > consistent enough. It will convert an associative array to a hash as > it is supposed to, but it will also convert an array using the > equivalent of Hash[*flatten] in certain cases that are not well enough > defined. So I've been thinking of using this instead: > > # Converts an associative array into a hash. > # > # a = [ [:a,1], [:b,2] ] > # a.to_h #=> { :a=>1, :b=>2 } > # > # When a non-standard associative array is used, > # the result is as follows: > # > # a = [ [:a,1,2], [:b,2], [:c], :d ] > # a.to_h #=> { :a=>[1,2], :b=>2, :c=>nil, :d=>nil } > # > # If the fist entry of two or more values is the same, then > # they will be joined using #concat. > # > # a = [ [:a,1,2], [:a,2], [:a,7], :a ] > # a.to_h #=> { :a=>[1,2,2,7,nil] } > # > # If +arrayed+ is set it will maintain trailing arrays regardless. > # > # a = [ [:a,1,2], [:b,3], :c ] > # a.to_h(true) #=> { :a=>[1,2], :b=>[3], :c=>[] } > > def to_h(arrayed=nil) > h = {} > each do |k,*v| > h[k] ||= [] > h[k].concat(v) > end > unless arrayed > h.each do |k,v| > if v.size < 2 > h[k] = v[0] > end > end > end > h > end > > This means an array like [1,2,3,4] cannot use #to_h to convert to a > hash, but must use Hash[*array] instead. > > Thoughts? I like this way you propose. There was a discussion [1] on ruby-talk. I think it matches now the use cases better than before. I also should rewrite Enumerator#to_h this way. [1] http://www.ruby-forum.com/topic/177285#new regards, Sandor Sz?cs -- From transfire at gmail.com Fri Feb 6 09:14:31 2009 From: transfire at gmail.com (Trans) Date: Fri, 6 Feb 2009 06:14:31 -0800 (PST) Subject: [Facets] Array#to_h In-Reply-To: <784EBA66-1124-4A2A-BD67-F5CB2F951F8F@fu-berlin.de> References: <5e430322-0df0-4581-9cbb-b0342fb71e73@w39g2000prb.googlegroups.com> <784EBA66-1124-4A2A-BD67-F5CB2F951F8F@fu-berlin.de> Message-ID: <6e28c471-7f11-4c05-89a6-f191a2158038@e1g2000pra.googlegroups.com> On Feb 5, 4:44?pm, Sandor Sz?cs wrote: > I like this way you propose. > There was a discussion [1] on ruby-talk. I think it matches now the > use cases better than before. I also should rewrite Enumerator#to_h > this way. > > [1]http://www.ruby-forum.com/topic/177285#new Thanks. I think I'll cc my idea to that thread. I was thinking about it some more and I was thinking about how the various opitions on it might be addressed. So I came up with this: # Converts an associative array into a hash. # # a = [ [:a,1], [:b,2] ] # a.to_h #=> { :a=>1, :b=>2 } # # When a mixed or multi-element accociative array # is used, the result is as follows: # # a = [ [:a,1,2], [:b,2], [:c], :d ] # a.to_h #=> { :a=>[1,2], :b=>2, :c=>nil, :d=>nil } # # If the fist entry of the subelements is the same, then # the values will be merged using #concat. # # a = [ [:a,1,2], [:a,3], [:a,4], [:a], :a ] # a.to_h #=> { :a=>[1,2,3,4,nil,nil] } # # The +mode+ can be set to effect the result. If it is # set to +:array+ or +true+ then trailing arrays # will be kept. Eg. # # a = [ [:a,1,2], [:b,3], [:c] ] # a.to_h:array #=> { :a=>[1,2], :b=>[3], :c=>[] } # # Setting mode to +:splat+ will produce the same result # as calling +Hash[*array]+. # # a = [:a,1,:b,2,:c] # a.to_h:splat #=> { :a=>1, :b=>2, :c=>nil } # # Setting mode to +:flat+ will produce the same result # as calling +Hash[*array.flatten]+. # # a = [:a,1,[:b,2,:c]] # a.to_h:flat #=> { :a=>1, :b=>2, :c=>nil } # # NOTE: The use of a +values+ parameter has been deprecated # because that functionality is as simple as: # # array1.zip(array2).to_h # # CREDIT: Trans #-- # The +True+ option in the case statement provides some # backward compatibility with the previous versions of this # method. #++ def to_h(mode=nil) case mode when :splat a = dup a << nil if a.size % 2 == 1 Hash[*a] when :flat a = flatten a << nil if a.size % 2 == 1 Hash[*a] when :array, True h = {} each do |k,*v| h[k] ||= [] h[k].concat(v) end h else h = {} each do |k,*v| h[k] ||= [] h[k].concat(v) end h.each do |k,v| h[k] = v[0] if v.size < 2 end h end end By using a +type+ we can offer a variety of common means of conversion. Of course, on the other hand we could just make them all separate methods, ie. #to_h, #to_h_array, #to_h_splat, #to_h_flat. T. From sandor.szuecs at fu-berlin.de Sun Feb 8 11:16:52 2009 From: sandor.szuecs at fu-berlin.de (=?ISO-8859-1?Q?Sandor_Sz=FCcs?=) Date: Sun, 8 Feb 2009 17:16:52 +0100 Subject: [Facets] Array#to_h In-Reply-To: <6e28c471-7f11-4c05-89a6-f191a2158038@e1g2000pra.googlegroups.com> References: <5e430322-0df0-4581-9cbb-b0342fb71e73@w39g2000prb.googlegroups.com> <784EBA66-1124-4A2A-BD67-F5CB2F951F8F@fu-berlin.de> <6e28c471-7f11-4c05-89a6-f191a2158038@e1g2000pra.googlegroups.com> Message-ID: <731DC03B-FEB3-4BFF-95B8-81C1CD4EDCC1@fu-berlin.de> On 06.02.2009, at 15:14, Trans wrote: > By using a +type+ we can offer a variety of common means of > conversion. Of course, on the other hand we could just make them all > separate methods, ie. #to_h, #to_h_array, #to_h_splat, #to_h_flat. You can do both and let the choice to the user. What do you think about to just dispatch to the methods? def to_h_array .. end .. def to_h(mode) case mode when :array to_h_array .. end regards, Sandor Sz?cs -- From transfire at gmail.com Sun Feb 8 13:01:59 2009 From: transfire at gmail.com (Trans) Date: Sun, 8 Feb 2009 10:01:59 -0800 (PST) Subject: [Facets] Array#to_h In-Reply-To: <731DC03B-FEB3-4BFF-95B8-81C1CD4EDCC1@fu-berlin.de> References: <5e430322-0df0-4581-9cbb-b0342fb71e73@w39g2000prb.googlegroups.com> <784EBA66-1124-4A2A-BD67-F5CB2F951F8F@fu-berlin.de> <6e28c471-7f11-4c05-89a6-f191a2158038@e1g2000pra.googlegroups.com> <731DC03B-FEB3-4BFF-95B8-81C1CD4EDCC1@fu-berlin.de> Message-ID: On Feb 8, 11:16?am, Sandor Sz?cs wrote: > On 06.02.2009, at 15:14, Trans wrote: > > > By using a +type+ we can offer a variety of common means of > > conversion. Of course, on the other hand we could just make them all > > separate methods, ie. #to_h, #to_h_array, #to_h_splat, #to_h_flat. > > You can do both and let the choice to the user. > What do you think about to just dispatch to the methods? > > def to_h_array > ? ?.. > end > .. > def to_h(mode) > ? case mode > ? when :array > ? ?to_h_array > ? .. > end I agree. I working on it and should have it done it a bit. Thanks, T. From transfire at gmail.com Wed Feb 11 10:16:46 2009 From: transfire at gmail.com (Trans) Date: Wed, 11 Feb 2009 07:16:46 -0800 (PST) Subject: [Facets] Array#to_h In-Reply-To: References: <5e430322-0df0-4581-9cbb-b0342fb71e73@w39g2000prb.googlegroups.com> <784EBA66-1124-4A2A-BD67-F5CB2F951F8F@fu-berlin.de> <6e28c471-7f11-4c05-89a6-f191a2158038@e1g2000pra.googlegroups.com> <731DC03B-FEB3-4BFF-95B8-81C1CD4EDCC1@fu-berlin.de> Message-ID: <7171e7a3-9012-4bbf-9d1e-88cbd584d624@v13g2000yqm.googlegroups.com> Ok. Here is what I've arrived at: class Array # Converts an array into a hash. Converting an array # into a hash is not a one-to-one conversion, for this # reason #to_h examines at the array being converted # and then dispatches the conversion to the most sutiable # specialized function. There are three possiblities for this. # # If the array is a collection of perfect pairs, like that # which Hash#to_a generates, then conversion is handled by # #to_h_flat. # # a = [ [:a,1], [:b,2] ] # a.to_h #=> { :a=>1, :b=>2 } # # If the array contains only arrays, but are not perfect pairs, # then #to_h_multi is called. # # a = [ [:a,1,2], [:b,2], [:c], [:d] ] # a.to_h #=> { :a=>[1,2], :b=>[2], :c=>[], :d=>[] } # # If the array contians objects other then arrays then # the #to_h_splat method is called. # # a = [ [:a,1,2], 2, :b, [:c,3], 9 ] # a.to_h #=> { [:a,1,2]=>2, :b=>[:c,3], 9=>nil } # # Finally, a particular dispatch can be forced by # specifying the +mode+ of conversion, eg. +:multi+, # +:splat+, +:flat+, +:assoc+, etc. # # Setting +mode+ to +true+ is the same as setting it +:multi+. # This has been left in for backward compatability. # # NOTE: The use of a +values+ parameter has been deprecated # because that functionality is as simple as: # # array1.zip(array2).to_h # # CREDIT: Robert Klemme # CREDIT: Trans # #-- # The +True+ option in the case statement provides some # backward compatability with the previous versions of this # method. #++ def to_h(mode=nil) case mode when :splat to_h_splat when :flat to_h_flat when :multi, true to_h_multi when :assoc to_h_assoc end pairs = true mixed = false each do |e| case e when Array pairs = false if e.size > 2 else mixed = true end end if mixed to_h_splat elsif pairs to_h_flat else to_h_multi end end # This is equivalent to Hash[*array], but it will pad # the array with a +nil+ object if there are not an even number # of elements. # # a = [:a,1,:b,2,:c] # a.to_h_splat #=> { :a=>1, :b=>2, :c=>nil } # def to_h_splat a = dup a << nil if a.size % 2 == 1 Hash[*a] end # This is equivalent to Hash[*array.flatten], but it will pad # the array with a +nil+ object if there are not an even number # of elements. # # a = [:a,1,[:b,2,:c]] # a.to_h_flat #=> { :a=>1, :b=>2, :c=>nil } # def to_h_flat a = flatten a << nil if a.size % 2 == 1 Hash[*a] end # When a mixed or multi-element accociative array # is used, the result is as follows: # # a = [ [:a,1,2], [:b,2], [:c], :d ] # a.to_h #=> { :a=>[1,2], :b=>[2], :c=>[], :d=>[] } # # If the fist entry of any subelements are the same, then # the value will be set to the last occuring value. # # a = [ :x, [:x], [:x,1,2], [:x,3], [:x,4] ] # a.to_h_assoc #=> { :x=>4 } # def to_h_assoc h = {} each do |k,*v| h[k] = v end h end # When a mixed or multi-element accociative array # is used, the result is as follows: # # a = [ [:a,1,2], [:b,2], [:c], :d ] # a.to_h #=> { :a=>[1,2], :b=>[2], :c=>[], :d=>[] } # # If the fist entry of the subelements is the same, then # the values will be merged using #concat. # # a = [ [:a,1,2], [:a,3], [:a,4], [:a], :a ] # a.to_h_multi #=> { :a=>[1,2,3,4,nil,nil] } # def to_h_multi h = {} each do |k,*v| h[k] ||= [] h[k].concat(v) end h end end class Hash # Any array values with less one or no elements will have the element # or nil set as the value instead. # # h = { :a=>[1], :b=>[1,2], :c=>3, :d=>[] } # h.dearray_values #=> { :a=>1, :b=>1, :c=>3, :d=>nil } # # CREDIT: Trans def dearray_values(index=0) h = {} each do |k,v| case v when Array h[k] = v[index] || v[-1] else h[k] = v end end h end # Any array values with less one or no elements will have the element # or nil set as the value instead. # # h = { :a=>[1], :b=>[1,2], :c=>3, :d=>[] } # h.dearray_values #=> { :a=>1, :b=>[1,2], :c=>3, :d=>nil } # # CREDIT: Trans def dearray_singluar_values h = {} each do |k,v| case v when Array h[k] = v[0] if v.size < 2 else h[k] = v end end h end end From transfire at gmail.com Wed Feb 11 10:20:24 2009 From: transfire at gmail.com (Trans) Date: Wed, 11 Feb 2009 07:20:24 -0800 (PST) Subject: [Facets] Array#to_hash Message-ID: <38aa4ab1-4b29-41f4-b0ce-b4d53aa771bf@v42g2000yqj.googlegroups.com> Would any problems arise from extending Array with this? # Convert an array into an indexed hash. # # [:a,:b,:c].to_hash #=> {0=>:a,1=>:b,2=>:c} # def to_hash h = {} each_with_index do |v, i| h[i] = v end h end Thanks, T. From sandor.szuecs at fu-berlin.de Thu Feb 26 16:45:31 2009 From: sandor.szuecs at fu-berlin.de (=?ISO-8859-1?Q?Sandor_Sz=FCcs?=) Date: Thu, 26 Feb 2009 22:45:31 +0100 Subject: [Facets] Bugs in Array#to_h Message-ID: Hi, I think this behaviour is not intended. a = [:a, 1, [:b, 2, :c]] a.to_h_flat == a.to_h(:flat) #=> false a.to_h(:flat) #=> {:a=>1, [:b, 2, :c]=>nil} a.to_h_flat #=> {:a=>1, :b=>2, :c=>nil} a.to_h_multi == a.to_h(:multi) #=> false a.to_h_multi #=> {:a=>[], 1=>[], :b=>[2, :c]} a.to_h(:multi) #=> {:a=>1, [:b, 2, :c]=>nil} a.to_h_assoc == a.to_h(:assoc) #=> false a.to_h(:assoc) #=> {:a=>1, [:b, 2, :c]=>nil} a.to_h_assoc #=> {:a=>[], 1=>[], :b=>[2, :c]} splat is ok a.to_h_splat == a.to_h(:splat) #=> true I added testcases for all these cases. You can pull it from git://github.com/szuecs/facets.git regards, Sandor Sz?cs -- From transfire at gmail.com Fri Feb 27 10:12:20 2009 From: transfire at gmail.com (trans) Date: Fri, 27 Feb 2009 07:12:20 -0800 (PST) Subject: [Facets] Bugs in Array#to_h In-Reply-To: References: Message-ID: <8e30df70-d2fb-4608-82b4-e05c99bc036c@w34g2000yqm.googlegroups.com> On Feb 26, 4:45?pm, Sandor Sz?cs wrote: > Hi, > > I think this behaviour is not intended. > > a = [:a, 1, [:b, 2, :c]] > > a.to_h_flat == a.to_h(:flat) #=> false > a.to_h(:flat) ? #=> {:a=>1, [:b, 2, :c]=>nil} > a.to_h_flat ? ? #=> {:a=>1, :b=>2, :c=>nil} > > a.to_h_multi == a.to_h(:multi) ?#=> false > a.to_h_multi ? ?#=> {:a=>[], 1=>[], :b=>[2, :c]} > a.to_h(:multi) ?#=> {:a=>1, [:b, 2, :c]=>nil} > > a.to_h_assoc == a.to_h(:assoc) ?#=> false > a.to_h(:assoc) ?#=> {:a=>1, [:b, 2, :c]=>nil} > a.to_h_assoc ? ?#=> {:a=>[], 1=>[], :b=>[2, :c]} > > splat is ok > a.to_h_splat == a.to_h(:splat) ?#=> true > > I added testcases for all these cases. You can pull it from > git://github.com/szuecs/facets.git > > regards, Sandor Sz?cs Thanks. Fixed. T. From transfire at gmail.com Fri Feb 27 10:04:23 2009 From: transfire at gmail.com (Trans) Date: Fri, 27 Feb 2009 07:04:23 -0800 (PST) Subject: [Facets] New Feature - String#file Message-ID: require 'facets/functor' class String # Use fluent notation for making file directives. # # '~/trans/Desktop/notes.txt'.file.mtime # def file f = self Functor.new do |op, *a| File.send(op, f, *a) end end end From sandor.szuecs at fu-berlin.de Fri Feb 27 16:19:46 2009 From: sandor.szuecs at fu-berlin.de (=?ISO-8859-1?Q?Sandor_Sz=FCcs?=) Date: Fri, 27 Feb 2009 22:19:46 +0100 Subject: [Facets] Bug in Hash#dearray_singluar_values Message-ID: <16164E69-9C0F-49B5-B8AB-12AD15CD2B5B@fu-berlin.de> Hi, I fixed the doku and the method according your comment. Before this fix it returns: { :a=>1, :c=>3, :d=>nil } --- a/lib/core/facets/to_hash.rb +++ b/lib/core/facets/to_hash.rb @@ -27,7 +27,7 @@ class Hash # or nil set as the value instead. # # h = { :a=>[1], :b=>[1,2], :c=>3, :d=>[] } - # h.dearray_values #=> { :a=>1, :b=>[1,2], :c=>3, :d=>nil } + # h.dearray_singluar_values #=> { :a=>1, :b=>[1,2], :c=>3, :d=>nil } # # CREDIT: Trans @@ -36,7 +36,7 @@ class Hash each do |k,v| case v when Array - h[k] = v[0] if v.size < 2 + h[k] = (v.size < 2) ? v[0] : v else h[k] = v end I hope the comment was correct, not the method! I added tests for Hash#dearray_singluar_values and Hash#dearray_values, too. You can pull the changes from my github repo. Regards, Sandor Sz?cs -- From transfire at gmail.com Sat Feb 28 14:45:50 2009 From: transfire at gmail.com (trans) Date: Sat, 28 Feb 2009 11:45:50 -0800 (PST) Subject: [Facets] Bug in Hash#dearray_singluar_values In-Reply-To: <16164E69-9C0F-49B5-B8AB-12AD15CD2B5B@fu-berlin.de> References: <16164E69-9C0F-49B5-B8AB-12AD15CD2B5B@fu-berlin.de> Message-ID: On Feb 27, 4:19?pm, Sandor Sz?cs wrote: > Hi, > > I fixed the doku and the method according your comment. > Before this fix it returns: { :a=>1, :c=>3, :d=>nil } > > --- a/lib/core/facets/to_hash.rb > +++ b/lib/core/facets/to_hash.rb > @@ -27,7 +27,7 @@ class Hash > ? ? # or nil set as the value instead. > ? ? # > ? ? # ? h = { :a=>[1], :b=>[1,2], :c=>3, :d=>[] } > - ?# ? h.dearray_values ?#=> { :a=>1, :b=>[1,2], :c=>3, :d=>nil } > + ?# ? h.dearray_singluar_values ?#=> ? > { :a=>1, :b=>[1,2], :c=>3, :d=>nil } > ? ? # > ? ? # CREDIT: Trans > > @@ -36,7 +36,7 @@ class Hash > ? ? ? each do |k,v| > ? ? ? ? case v > ? ? ? ? when Array > - ? ? ? ?h[k] = v[0] if v.size < 2 > + ? ? ? ?h[k] = (v.size < 2) ? v[0] : v > ? ? ? ? else > ? ? ? ? ? h[k] = v > ? ? ? ? end > > I hope the comment was correct, not the method! > > I added tests for Hash#dearray_singluar_values and > Hash#dearray_values, too. > > You can pull the changes from my github repo. Right O. Thanks Sandor. T.