[MacRuby-devel] HotCocoa LayoutView Patch

2009-05-22 Thread dan sinclair 

Hello,

Attached is a simple patch to make the ability to enable a border  
around a layout_view available without being in debug mode. It also  
allows different colours to be set on each layout_view. Makes it  
easier, for me at least, to figure out where all the bounding boxes  
are sitting.


Does this make sense to go back into SVN? Anything that should be  
changed to make it committable?


Thanks,
dan



frame_color.diff
Description: Binary data


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Experimental branch status

2009-05-28 Thread dan sinclair 


2. Writing tutorials / sample code for MacRuby, since anyone who's  
new to the project needs a place to start.




Speaking of tutorials, I created a couple tutorials on getting started  
with HotCocoa. They're available at:


  http://everburning.com/news/heating-up-with-hotcocoa-part-i/
  http://everburning.com/news/heating-up-with-hotcocoa-part-iI/
  http://everburning.com/news/heating-up-with-hotcocoa-part-iII/
  http://everburning.com/news/heating-up-with-hotcocoa-on-github/


dan
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] HotCocoa status update

2009-05-28 Thread dan sinclair 
I've been shooting around in the dark with HotCocoa for a few days.  
Adding things here and there. Is there a priority list of things to  
do, or everything is equally good?


Is most HotCocoa discussion done on this list and in IRC?

Thanks,
dan



On May 29, 2009, at 1:55 AM, Matt Aimonetti wrote:

Here is a quick update to let you know the progress made on HotCocoa  
in trunk.


* new MVC template. The template in HotCocoa 0.4 is great but as  
soon as you try to build a rich/complicated GUI, you start having to  
build your own "view" system. We spent some time designing a new  
templating solution for HotCocoa. You will still be able to use the  
one file type approach provided by 0.4, but we are trying to set  
some conventions for people in need of a MVC approach.
Having well defined conventions makes delegation and code  
organization easier.


* Documentation app. We started working on a documentation app to  
provide Cocoa and HotCocoa documentation. The source code is  
available at  http://github.com/mattetti/macruby-doc-app/ but will  
soon be moved to trunk. To play with the app, you need to have the  
latest version of trunk built on your machine. The application uses  
the Cocoa docsets and parses the HotCocoa mappings to show available  
methods, delegations and cocoa doc.
Most of the basic functionalities are available, we are now going to  
spend some time making the app look good and intuitive.


* HotCocoa mappings. With more and more people using HotCocoa,  
mappings are being improved and extended.


Todos:

* Better integration between Interface Builder and HotCocoa. Imagine  
defining a startup view using Interface Builder and then manage  
everything else using HotCocoa using the newly designed HotCocoa MVC  
conventions. We have some ideas on how to do that in a transparent  
way but more experiments are required.


* Tests. We would like to see HotCocoa being better tested and also  
provide a decent testing solution for developers.


* Rucola integration. Rucola is a very interesting and inspiring  
RubyCocoa project. We are looking forward to work closely with the  
Eloy Duran to offer the same type of experience for MacRuby/HotCocoa.


* Wrap commonly used obj-c libraries and document the process.


As usual, your help would be appreciated.

- Matt
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Contributions (Was: Experimental branch status)

2009-05-29 Thread dan sinclair 
Is the goal to keep all of the tutorials on the main macruby site? I  
enjoy writing them but prefer to post them to everburning to keep them  
with the rest of my stuff.  If the goal is to have them on the website  
I can port the 3 HotCocoa bits I've written over to whatever it is the  
website uses.


Along with that, there is no good way to get to the trac to view  
tickets on the website. The only link, that I've found, is to use the  
file a ticket section of the contact page and navigate out from there.  
Might be a good idea to make it easier for people to submit bugs/find  
bugs to work on.


dan



On May 29, 2009, at 6:31 PM, Laurent Sansonetti wrote:


So, to recap, I think the following contributions will be welcome:

- Maintaining the website (blog, content, etc.) and writing  
tutorials. There are lots of very interesting blog posts around that  
could I think be transformed into a tutorial or into a recipe  
(shorter tutorial). I think we need more recipes, for instance how  
to embed MacRuby in your app, how to use a specific and complex  
Cocoa class (NSOutlineView/NSTableView/etc.) in Ruby, etc.


- Writing / translating sample code for MacRuby. We will bundle it  
in the MacRuby distribution. If you wrote anything interesting in  
MacRuby that could be used as a sample code, let us now. Creating  
new sample code is cool, but porting an existing Objective-C sample  
code is good too.


- Specs: working on the 1.8 -> 1.9 rubyspec transition (see Eloy's  
message above). Eloy is currently doing all the specs maintenance as  
well and I think he will not be against help :) Also, we recently  
started writing MacRuby-specific specs, they need to be extended.  
Finally, we need to start working on passing the core specs (we only  
did language so far).


- Porting C extensions to the Ruby FFI API. We started working on a  
compatible Ruby FFI API, we still have a plan to support C  
extensions but not in the very near future and the performance will  
not be great, FFI will be faster. Also if most of the well-known C  
extensions have been ported, we might simply decide to not support C  
extensions, which is one less thing to do. Also, working on Ruby FFI- 
compatible libraries will make JRuby / Rubinius / etc. users happy :)


- HotCocoa: I will leave this part to Rich and Matt, but I think  
they will be mostly interested in mappings. Try to create a HotCocoa  
app, then contribute mappings for things that do not exist (or  
improve the existing ones by contributing custom methods, etc.).


- Core: there are lots of things to do, if you feel hacking on the  
low-level bits. We maintain a TODO file which contains a few things  
that still need to be done. At this point, the JIT compiler is  
almost finished (AOT is maybe finished at 10%, though) and the VM is  
still under development. A good way to start hacking is to run the  
test_vm.rb test suite, pick a failing test and try to fix it.  
Contributing new failing tests is also highly welcome, you can  
simply use the miniruby executable and try to make it crash (it's  
not hard, you will see).


- ... anything more? :)

Laurent

On May 29, 2009, at 6:57 AM, Eloy Duran wrote:

I haven't actively spoken about this with Laurent over the last  
week, but afaik not much changed since last time, which means that  
the support is not nearly far enough to start using it. We decided  
that we want the FFI specs in the repo in order to finish this work  
appropriately, which would need work to be converted from RSpec to  
MSpec.


Luckily Brian Ford (from the rubyspec project) was already planning  
on incorporating them. I haven't had time to check if they're in  
yet. So this is another area where people could help out. By  
porting the ruby-ffi specs to mspec and integrating them into the  
rubyspec.


Cheers,
Eloy

On May 29, 2009, at 1:28 PM, Chuck Remes wrote:

How is progress on support FFI? That seems to be the new ruby-way  
for interfacing to native code supported by JRuby, Rubinius and to  
some extent the 1.9.x codeline. With FFI built in, as gems are  
updated to support the other ruby interpreters and/or compilers  
then MacRuby would be supported for "free" through those efforts.


cr

On May 28, 2009, at 11:42 PM, Matt Aimonetti wrote:

The other thing that needs to be done is to port/fix the popular  
Ruby gems which don't work on MacRuby yet. Also, writing wrappers  
for common obj-c libraries/frameworks would be very useful.


If you are interested in writing tutorials/articles, feel free to  
contact me offline so I can show you how to use our blog engine  
tool. (I think Rich is planning on releasing a tutorial on how to  
do that, but that might not happen right away)


- Matt

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
M

Re: [MacRuby-devel] 40g to build MacRuby?

2009-05-30 Thread dan sinclair 

A checkout of SVN trunk takes a total of 135meg compiled on my machine.

dan


On May 30, 2009, at 3:39 AM, Dave Chilson wrote:

I've tried to build 0.4 of MacRuby a few times, I have about 40G  
free on my drive and am running out of space. This is a standard  
Leopard install, am I doing something wrong or does it really take  
more than 40g of space to build MacRuby.


-Dave
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] Porting Rational

2009-07-28 Thread dan sinclair 

Hello,

I started to port the Rational code to the objc interfaces.  There are  
currently 8 specs left for rational that I haven't been able to get to  
pass. As part of the rational I also did a bit of the Complex code but  
there are some specs in there that are segv'ing so I'm not sure how  
many of those pass at the moment.


Patch is attached. Let me know if I need to fix anything up.

Thanks,
dan

(I would have logged this into trac but I can't seem to login at the  
moment. Continuously redirects between http://www.macruby.org/auth/ 
login and https://www.macruby.org/auth/login)




rational_complex_1.diff
Description: Binary data


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Porting Rational

2009-07-29 Thread dan sinclair 
As requested I grabbed the latest rational.c and complex.c from ruby  
SVN and got them working under MacRuby. Patch is attached.


dan



rational_complex_2.diff.gz
Description: GNU Zip compressed data






On Jul 28, 2009, at 11:54 PM, dan sinclair wrote:


Hello,

I started to port the Rational code to the objc interfaces.  There  
are currently 8 specs left for rational that I haven't been able to  
get to pass. As part of the rational I also did a bit of the Complex  
code but there are some specs in there that are segv'ing so I'm not  
sure how many of those pass at the moment.


Patch is attached. Let me know if I need to fix anything up.

Thanks,
dan

(I would have logged this into trac but I can't seem to login at the  
moment. Continuously redirects between http://www.macruby.org/auth/login 
 and https://www.macruby.org/auth/login)



___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] Add Integer#ord

2009-08-03 Thread dan sinclair 

Attached patch ports Integer#ord from Ruby 1.9.

dan



integer_ord.diff
Description: Binary data


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] NSNumber boolean spec

2009-08-03 Thread dan sinclair 
The attached patch gets the NSNumber boolean conversion spec working.   
I'm not sure if the change is correct but I changed the spec from  
should != to should_not == and it appears to be working correctly now.


dan



numeric_spec.diff
Description: Binary data


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] Base64 specs

2009-08-04 Thread dan sinclair 

Hello,

The attached patch marks some specs that don't execute on Ruby 1.9.2  
for me.  The other Base64 specs that are broken are due to the TODO in  
vm_method.c,  rb_mod_modfunc to do with changing scope.


dan



base64.diff
Description: Binary data


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Base64 specs

2009-08-06 Thread dan sinclair 
As far as I can tell, those methods don't exist in the Base64 class on  
Ruby 1.9.2.  Not sure if I'm missing something but I didn't find them.


dan





On Aug 6, 2009, at 3:53 AM, Eloy Duran wrote:


Hey Dan,

By just reading the patch it seems there are no new versions of  
these examples on how the method works on 1.9.x. Could you please  
add those as well?


Cheers,
Eloy

On Aug 5, 2009, at 5:44 AM, dan sinclair wrote:


Hello,

The attached patch marks some specs that don't execute on Ruby  
1.9.2 for me.  The other Base64 specs that are broken are due to  
the TODO in vm_method.c,  rb_mod_modfunc to do with changing scope.


dan


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Base64 specs

2009-08-09 Thread dan sinclair 
Well, not all of the Base64 stuff was removed. Of the four base64 test  
files, two of them are obsolete and two of them appear to still be  
valid.


b64encode_spec.rb and decode_b_spec.rb are both invalid while  
decode64_spec.rb and encode64_spec.rb are both valid.


dan


On Aug 7, 2009, at 2:48 AM, Eloy Duran wrote:

Ok I see, Base64 was removed from 1.9 in favour of using Array#pack  
and String#unpack. Which means we only need to omit it from the ruby  
specific mspec script. In our case macruby.mspec. If it's not yet in  
the obsolete list of libraries in the ruby.1.9.mspec script, then it  
should be added there.


Eloy

On 7 aug 2009, at 02:13, dan sinclair wrote:

As far as I can tell, those methods don't exist in the Base64 class  
on Ruby 1.9.2.  Not sure if I'm missing something but I didn't find  
them.


dan





On Aug 6, 2009, at 3:53 AM, Eloy Duran wrote:


Hey Dan,

By just reading the patch it seems there are no new versions of  
these examples on how the method works on 1.9.x. Could you please  
add those as well?


Cheers,
Eloy

On Aug 5, 2009, at 5:44 AM, dan sinclair wrote:


Hello,

The attached patch marks some specs that don't execute on Ruby  
1.9.2 for me.  The other Base64 specs that are broken are due to  
the TODO in vm_method.c,  rb_mod_modfunc to do with changing scope.


dan


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] URI specs

2009-08-09 Thread dan sinclair 

Hello,

I started poking at the URI specs to see what I could get working. The  
attached patch was required to make the specs run (URI provides 11  
arguments to initialize).


I then started taking a look at why the equality spec fails and have  
tracked it back to the dup call not returning the same values in the  
duplicate object. This can be seen by doing a self.to_s and uri.to_s  
in the normalize function of lib/uri/generic.rb.


self.to_s -> http://example.com/#fragMENT
uri.to_s ->  http://example.com/

For some reason, the fragment instance variable is being dropped from  
the duplicated object while all of the other instance variables are  
being copied over.


You can see the same behaviour with the following script


class  Foo
  def initialize(a, b, c, d, e, f, g, h, i, j, k)
@a = a
@b = b
@c = c
@d = d
@e = e
@f = f
@g = g
@h = h
@i = i
@j = j
@k = k
  end

  def to_s
"#...@a} #...@b} #...@c} #...@d} #...@e} #...@f} #...@g} #...@h} #...@i} #...@j} 
#...@k}"
  end
end

f = Foo.new("a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k")
g = f.dup

puts f.to_s
puts g.to_s
---

titania:test dj2$ macruby ./dup.rb
a b c d e f g h i j k
a b c d e f g h i j false

dan




vm_argc.diff
Description: Binary data




___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] Fixing ext/json

2009-08-17 Thread dan sinclair 

Hello,

I've been taking a poke at ext/json for the last few days attempting  
to get JSON support working again. I've got it compiling but have run  
into an issue with memory management and the garbage collector that  
I've been unable to get past.


I've attached my current diff of changes to get JSON working. With  
this diff applied requiring json will crash with:


unknown: [BUG] destination 0x100feb300 isn't in the auto zone

I've tracked it down to ext/json/lib/json/common.rb line 59 (at least,  
it never gets past that line that I've seen)


self.state = generator::State

Commenting out this line gets further (require works and I can turn  
{"a" => 1} into JSON. Missing module_function causes JSON.parse to  
fail).


My test file is:

puts "Requiring"
require 'json'
puts "Required"
require 'pp'

puts "to_json"
a = {"a" => 1}.to_json
puts "parse"
pp JSON.parse(a)
puts "done"

Thoughts?

Thanks,
dan




json.diff
Description: Binary data


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Fixing ext/json

2009-08-19 Thread dan sinclair 

I've simplified the crash to happen outside of the JSON extension.

module Test
  class << self
attr_accessor :foo
  end
end

Test.foo = "asdf"

unknown: [BUG] destination 0x100fe3fb0 isn't in the auto zone
MacRuby version 0.5 (ruby 1.9.0) [universal-darwin9.0, x86_64]

dan



On Aug 17, 2009, at 10:37 PM, dan sinclair wrote:


Hello,

I've been taking a poke at ext/json for the last few days attempting  
to get JSON support working again. I've got it compiling but have  
run into an issue with memory management and the garbage collector  
that I've been unable to get past.


I've attached my current diff of changes to get JSON working. With  
this diff applied requiring json will crash with:


   unknown: [BUG] destination 0x100feb300 isn't in the auto zone

I've tracked it down to ext/json/lib/json/common.rb line 59 (at  
least, it never gets past that line that I've seen)


   self.state = generator::State

Commenting out this line gets further (require works and I can turn  
{"a" => 1} into JSON. Missing module_function causes JSON.parse to  
fail).


My test file is:

puts "Requiring"
require 'json'
puts "Required"
require 'pp'

puts "to_json"
a = {"a" => 1}.to_json
puts "parse"
pp JSON.parse(a)
puts "done"

Thoughts?

Thanks,
dan



___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Fixing ext/json

2009-08-19 Thread dan sinclair 
Ok, it crashes when typed into macirb but not when run as a script  
with macruby.


dan


On Aug 19, 2009, at 11:24 PM, dan sinclair wrote:


I've simplified the crash to happen outside of the JSON extension.

module Test
 class << self
   attr_accessor :foo
 end
end

Test.foo = "asdf"

unknown: [BUG] destination 0x100fe3fb0 isn't in the auto zone
MacRuby version 0.5 (ruby 1.9.0) [universal-darwin9.0, x86_64]

dan



On Aug 17, 2009, at 10:37 PM, dan sinclair wrote:


Hello,

I've been taking a poke at ext/json for the last few days  
attempting to get JSON support working again. I've got it compiling  
but have run into an issue with memory management and the garbage  
collector that I've been unable to get past.


I've attached my current diff of changes to get JSON working. With  
this diff applied requiring json will crash with:


  unknown: [BUG] destination 0x100feb300 isn't in the auto zone

I've tracked it down to ext/json/lib/json/common.rb line 59 (at  
least, it never gets past that line that I've seen)


  self.state = generator::State

Commenting out this line gets further (require works and I can turn  
{"a" => 1} into JSON. Missing module_function causes JSON.parse to  
fail).


My test file is:

puts "Requiring"
require 'json'
puts "Required"
require 'pp'

puts "to_json"
a = {"a" => 1}.to_json
puts "parse"
pp JSON.parse(a)
puts "done"

Thoughts?

Thanks,
dan



___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] call for help!

2009-11-01 Thread dan sinclair 
I created a document on Hotcocoa and Core Data (http://everburning.com/news/hotcocoa-and-core-data/ 
) a while ago when I was poking at it. There is a patch in Trac to  
have the .xcdatamodel files compiled automatically by Rake. Not sure  
if it ever got looked at.


dan



On Nov 1, 2009, at 3:36 PM, Laurent Sansonetti wrote:


Hi guys,

Things are shaping pretty nicely in trunk and we expect to release  
the second beta in a few days. We receive bug reports every day,  
it's great that people are testing it, and the final release will be  
awesome :-)


If you are interested in contributing to the project and you do not  
have the time or expertise to learn the source code & contribute  
patches, there are still crucial things that you could do:


1) Test as many Ruby code (gems, libraries) as possible with MacRuby  
and report us feedback, if the code crashes, runs slowly or leaks  
all your memory. If you report a runtime crash, it would be even  
better if you could take the time to reduce the problem into a few  
lines of Ruby, this saves us (well, me :)) time. Things we don't run  
yet (but should): rspec, mocha, activesupport (that's a big one!),  
etc.


2) Write Cocoa samples! MacRuby ships with a few samples but we  
desperately need more & better ones. If you play with MacRuby to do  
Cocoa development and use a specific framework/feature, it would be  
awesome if you could contribute it back as a sample application.  
Things we do not cover in samples: core data, bindings, opengl, many  
Cocoa classes, etc.


3) Document your experience as part of a website tutorial or recipe.  
We are trying to build a "documentation center" for MacRuby  
resources at http://www.macruby.org/documentation.html and we  
desperately need more content. Contributing new or enhancing  
existing content would be greatly appreciated.


Thanks!

Laurent
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] status and prospects of HotCocoa?

2010-06-10 Thread dan sinclair 
I've got a few tutorials and github apps that I've written with HotCocoa. I 
kinda stopped poking at it as I wasn't sure what the future held and decided to 
switch to straight up MacRuby/Cocoa for my last app.

Tutorials
* http://everburning.com/news/heating-up-with-hotcocoa-part-i/
* http://everburning.com/news/heating-up-with-hotcocoa-part-ii/
* http://everburning.com/news/heating-up-with-hotcocoa-part-iii/
* http://everburning.com/news/heating-up-with-hotcocoa-on-github/
* http://everburning.com/news/download-and-xml-parsing-with-hotcocoa/
* http://everburning.com/news/toolbars-with-hotcocoa/
* http://everburning.com/news/hotcocoa-and-core-data/

Github
* http://github.com/dj2/SilverLining   (Amazon EC2 Instance Browser)
* http://github.com/dj2/Rife (Start of a news reader)
* http://github.com/dj2/Postie (The app from the heating up 
tutorials)


dan


On 2010-06-10, at 2:05 PM, Gary Weaver wrote:

> These posts are a bit old now but:
> 
> Lots of examples linked to in this:
> * http://stufftohelpyouout.blogspot.com/2010/03/hotcocoamacruby-links.html
> 
> Some lame stuff I did in a few days:
> * 
> http://stufftohelpyouout.blogspot.com/2010/02/hotcocoa-app-to-track-time-on-tasks.html
> * 
> http://stufftohelpyouout.blogspot.com/2010/02/create-custom-icon-of-your-hotcocoa-app.html
> * 
> http://stufftohelpyouout.blogspot.com/2010/02/create-macruby-hotcocoa-app.html
> 
> This helped me get started in addition to the tutorial:
> * http://isaac.kearse.co.nz/2010/02/01/packaging-hotcocoa/
> (note: Isaac provided a patch to MacRuby to help with the file size thing)
> 
> The current story I think is that Rich Kilmer:
> http://wiki.github.com/richkilmer/hotcocoa/
> got pulled into other things and didn't have much time to keep it going, so 
> others have forked it I think:
> http://github.com/richkilmer/hotcocoa/network
> 
> Dan Sinclair had the most recent work on his branch of it but that was last 
> updated March 23, 2010:
> http://github.com/dj2/hotcocoa
> 
> I'm hoping Rich, Dan, and everyone else that is interested will continue work 
> on it. It was pretty cool!
> 
> Gary
> 
> 
> On 6/10/10 1:48 PM, Rich Morin wrote:
>> I'm curious about the status of HotCocoa.  Although it seems
>> like a very cool piece of technology, the activity level and
>> documentation status seem pretty minimal.  For example:
>> 
>>  *  http://www.macruby.org/trac/wiki/HotCocoaStatus shows
>> about thirty "partial" mappings; the rest are "unknown".
>> 
>>  *  http://www.macruby.org/trac/wiki/HotCocoaTutorial just
>> says "TODO".
>> 
>>  *  "MacRuby: The Definitive Guide" doesn't mention HotCocoa
>> in the Table of Contents.
>> 
>> If some folks here are using HotCocoa, I'd love to see some
>> examples, howtos, etc!
>> 
>> -r
>> 
> 
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] Building Cocoa Apps with MacRuby

2010-06-17 Thread dan sinclair 
Hello,

I wrote up some thoughts on building cocoa applications with MacRuby last night 
and would love to hear any thoughts other people have. You can see the article 
at http://everburning.com/news/ramblings-on-programming-cocoa-with-ruby/ .

I've been trying several different methods, HotCocoa, XCode templates, command 
line and haven't quite figured out a way that feels right and would love some 
insight from other developers.

Thanks,
dan


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Building Cocoa Apps with MacRuby

2010-06-17 Thread dan sinclair 
I tried using TextMate with XCode for a while but I didn't like having to 
switch back and forth between the two all the time. It felt clunky to develop 
in TextMate and build and see the debug output in XCode. Having to run XCode 
just to be able to build the application felt heavy. That was part of the 
reason why I switched to a pure Rakefile method.

dan



On 2010-06-17, at 1:43 PM, Rich Morin wrote:

> Xcode has some scripting capability.  Might you be able to
> hack up some scripts to automate away some of the hassle?
> 
> -r
> -- 
> http://www.cfcl.com/rdmRich Morin
> http://www.cfcl.com/rdm/resume [email protected]
> http://www.cfcl.com/rdm/weblog +1 650-873-7841
> 
> Technical editing and writing, programming, system design
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Building Cocoa Apps with MacRuby

2010-06-19 Thread dan sinclair 
The console task was just a simple way for me to run macrib and load up all the 
model files I have. Some of the stuff can work fine without a UI and this just 
gave me an easy way to test things. Similar to the Rails script/console.

dan




On Jun 19, 2010, at 2:56 PM, Dave Baldwin wrote:

> Hi Dan,
> 
> Good writeup.  I basically do as Michael Jackson has described, but with 
> Textmate.  I would also like to dispense with XCode.  I have moved away from 
> Hot Cocoa as it seems to be dead or unloved, but also found IB much easier to 
> use in the end.
> 
> Looking at the rakefile in your Touchstone project has left me a bit 
> confused.  What do you use the Console task for?
> 
> Thanks,
> 
> Dave.
> 
> On 17 Jun 2010, at 18:32, dan sinclair wrote:
> 
>> Hello,
>> 
>> I wrote up some thoughts on building cocoa applications with MacRuby last 
>> night and would love to hear any thoughts other people have. You can see the 
>> article at 
>> http://everburning.com/news/ramblings-on-programming-cocoa-with-ruby/ .
>> 
>> I've been trying several different methods, HotCocoa, XCode templates, 
>> command line and haven't quite figured out a way that feels right and would 
>> love some insight from other developers.
>> 
>> Thanks,
>> dan
>> 
>> 
>> ___
>> MacRuby-devel mailing list
>> [email protected]
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
> 
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Building Cocoa Apps with MacRuby

2010-06-19 Thread dan sinclair 
As long as I can still compile the .xib to a .nib outside of XCode then I'm 
fine with that. I still use XCode for the Core Data model editor. I just don't 
like having to add my files through the project system and build/debug in 
XCode. Prefer to do that from the command line.

dan





On Jun 19, 2010, at 3:10 PM, Matt Aimonetti wrote:

> Note that in Xcode 4, IB is not a separate app anymore, making this kind of 
> setup much harder :(
> 
> - Matt
> 
> On Sat, Jun 19, 2010 at 11:56 AM, Dave Baldwin  
> wrote:
> Hi Dan,
> 
> Good writeup.  I basically do as Michael Jackson has described, but with 
> Textmate.  I would also like to dispense with XCode.  I have moved away from 
> Hot Cocoa as it seems to be dead or unloved, but also found IB much easier to 
> use in the end.
> 
> Looking at the rakefile in your Touchstone project has left me a bit 
> confused.  What do you use the Console task for?
> 
> Thanks,
> 
> Dave.
> 
> On 17 Jun 2010, at 18:32, dan sinclair wrote:
> 
> > Hello,
> >
> > I wrote up some thoughts on building cocoa applications with MacRuby last 
> > night and would love to hear any thoughts other people have. You can see 
> > the article at 
> > http://everburning.com/news/ramblings-on-programming-cocoa-with-ruby/ .
> >
> > I've been trying several different methods, HotCocoa, XCode templates, 
> > command line and haven't quite figured out a way that feels right and would 
> > love some insight from other developers.
> >
> > Thanks,
> > dan
> >
> >
> > ___
> > MacRuby-devel mailing list
> > [email protected]
> > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
> 
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
> 
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Fibers and Enumerators

2010-08-11 Thread dan sinclair 
The em-synchrony project wraps a bunch of EventMachine code in fibers: 
http://github.com/igrigorik/em-synchrony

I know the author was looking at MacRuby and trying to figure out if fibers 
worked just the other day.

dan



On 2010-08-11, at 1:19 PM, Matt Massicotte wrote:

> Could you share some, or maybe provide a link?  I'm interested in the topic, 
> but unfamiliar with any specific use-cases.
> 
> Matt
> 
> On Aug 11, 2010, at 10:15 AM, Logan Bowers wrote:
> 
>> +1 for fibers. There is a class of problems made much simpler and/or 
>> possible with fibers that are not viable w/threads. 
>> 
>> Would love to see this make its way into MacRuby. 
>> 
>> Sent from my iPhone
>> 
>> On Aug 11, 2010, at 6:06 AM, Scott Thompson  wrote:
>> 
>>> 
>>> On Aug 11, 2010, at 7:23 AM, Louis-Philippe wrote:
>>> 
 Hi Scott,
 
 If you haven't done so already, you might want to have a look at:
 http://www.macruby.org/documentation/gcd.html
 
 it speaks of MacRuby integrating Apple's latest multi-threading strategy: 
 Grand Central Dispatch.
>>> 
>>> Grand Central Dispatch is a fine technology, and goes a long way toward 
>>> making concurrency much easier to implement.  But concurrent  execution is 
>>> only one form of multitasking and GCD is not a general solution to all 
>>> multitasking problems. In this particular case we are talking about 
>>> cooperatively scheduled coroutines which is multitasking, but not 
>>> necessarily concurrency.
>>> 
>>> In Grand Central Dispatch, work is broken up in to a number of small units 
>>> and those units are dispatched to queues.  Eventually a preemptive thread 
>>> will come along and pick up that work, run it (possibly in parallel with 
>>> other bits of work). When a thread runs some of the work, however, it runs 
>>> that work all the way through. 
>>> 
>>> Contrast that with a Fiber.  Like a block, a fiber represents a unit of 
>>> work you need to do, but it's work you can turn your attention to... spend 
>>> some time on, and then put down again at predefined spots.  Later, when you 
>>> are ready, you can pick up that work and continue at the same spot.  This 
>>> is multitasking, but not concurrency.  Consider a simple example:
>>> 
>>> my_fiber = Fiber.new do
>>> number = 0
>>> loop do
>>> Fiber.yield number
>>> number = number + 1
>>> end
>>> end
>>> 
>>> >> my_fiber.resume
>>> => 0
>>> 
>>> >> my_fiber.resume
>>> => 1
>>> 
>>> This is a coroutine. It has it's own execution context which is started 
>>> with the first resume, runs up until the yield, and then suspends 
>>> execution.  This is a simple example, but the coroutine could be calling 
>>> other subroutines, or other complex tasks, with the yield suspending 
>>> execution at any point along the way. At some point in the future, resume 
>>> may be called again and execution continues where it left off up until the 
>>> next time yield is called.
>>> 
>>> This type of multitasking would be hard to implement using GCD because GCD 
>>> focuses on concurrency. Since each GCD block runs to completion, the 
>>> solution would involve breaking up the Ruby code using the yield statements 
>>> as boundaries and then dispatching those blocks to a queue. But that 
>>> solution would quickly become untenable if you consider that the yield 
>>> statements might come... say... in the middle of a case:while statement, or 
>>> in the middle of a complex subroutine chain.
>>> 
>>> Another solution you might come up with is to submit the whole Fiber's 
>>> block as a single GCD block and implement the yield as acquiring some 
>>> multiprocessing lock (a semaphore or a condition lock for example).  If you 
>>> do that, then you've got the added overhead of a concurrency lock for each 
>>> yield and you've submitted a GCD block to a queue that contains an infinite 
>>> loop.  That block is going to sit at the end of the queue, consuming one of 
>>> the threads from the thread pool "forever".  If you get a bunch of these 
>>> running at once... GCD is not going to be happy with your train cars 
>>> sitting on his tracks.
>>> 
>>> Please don't get me wrong.  I __LOVE___ all the work that has gone into 
>>> integrating GCD into MacRuby.  But I don't see how GCD is going to help 
>>> someone implement the cooperative multitasking of Fibers, a Ruby 1.9 
>>> language feature.
>>> 
>>> Scott
>>> ___
>>> MacRuby-devel mailing list
>>> [email protected]
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>> ___
>> MacRuby-devel mailing list
>> [email protected]
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
> 
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Announcing Hubcap

2010-12-15 Thread dan sinclair 
I started working on something similar the other day. I've been looking 
specifically at GitHub issues but I've got a bunch of generic GitHub code that 
I started writing. You can see the code at https://github.com/dj2/Loom if 
you're interested.

I've been writing it outside of XCode so it's built using the Rakefile. The app 
itself is pretty basic at the moment, I've got the loading of issues there but 
there are currently two hard coded repos that it works with.

dan

On 2010-12-15, at 4:18 PM, Erik Michaels-Ober wrote:

> I'm pleased to announce that I will be building my first MacRuby app:
> a social GitHub client, which I'm calling Hubcap.
> 
> I am currently funding the project on Kickstarter: http://kck.st/ebH9MC
> 
> There's still time for you to pledge to receive early access to
> alpha/beta builds of the app. I would be honored to have the support
> and backing of the MacRuby community.
> 
> One of my goals is for Hubcap to be a killer app for MacRuby,
> encouraging Ruby developers to read the source code and create Mac
> apps of their own. I will also be submitting detailed bug reports as I
> uncover issues on the march to MacRuby 1.0!
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Documentation

2011-03-05 Thread dan sinclair 

What about enabling the wiki on the github repo?

dan



On Mar 5, 2011, at 10:32, Mark Rada  wrote:

> +1 for more documentation. More documentation is always a good thing.
> 
> Sent from my iDevice
> 
> On 2011-03-04, at 12:43 PM, Matt Aimonetti  wrote:
> 
>> I think that would be awesome!
>> 
>> - Matt
>> 
>> Sent from my iPhone
>> 
>> On Mar 4, 2011, at 5:13, Martin Hawkins  wrote:
>> 
>>> Is it something that would be of interest to people? If so, I would be 
>>> willing to get involved.
>>> 
>>> On 4 March 2011 09:57, Matt Aimonetti  wrote:
>>> Not really, the only other thing is the free online version of my book: 
>>> http://ofps.oreilly.com/titles/9781449380373/
>>> 
>>> - Matt 
>>> 
>>> On Fri, Mar 4, 2011 at 1:49 AM, Martin Hawkins  
>>> wrote:
>>> Is there an 'official' macruby documentation site? (Apart from the
>>> MacRuby Documentation page)
>>> It strikes me that there is a ton of gold dust in this forum that
>>> really needs to be pulled together so that people can access it
>>> easily.
>>> ___
>>> MacRuby-devel mailing list
>>> [email protected]
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>> 
>>> 
>>> ___
>>> MacRuby-devel mailing list
>>> [email protected]
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>> 
>>> 
>>> ___
>>> MacRuby-devel mailing list
>>> [email protected]
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>> ___
>> MacRuby-devel mailing list
>> [email protected]
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Is HotCocoa dead?

2011-03-24 Thread dan sinclair 
For me, I've basically dropped HotCocoa. After doing a few apps with it I 
quickly came to realize that I liked IB and building apps that way. The thing 
that I've missed from HotCocoa is all the little Ruby-ish extensions that it 
added to various classes. As I've built other apps I've been collecting up a 
few of those and decided to stuff them into a gem.

You can see them at https://github.com/dj2/Bean if you're interested.

Out of curiosity, what's the correct way to mark a gem as MacRuby only so I can 
push it up to rubygems.org?

dan




On Mar 24, 2011, at 8:56 PM, Matt Aimonetti wrote:

> Rich just sold his company to Living Social and I'm sure he's really busy ATM.
> If people are willing to hack on this project and maintain it (the core team 
> won't), we probably should move it to its own repo and give commit rights to 
> people.
> 
> Who's interested in created a HotCocoa team?
> 
> Thanks,
> 
> - Matt
> 
> 
> On Thu, Mar 24, 2011 at 11:37 AM, Manfred Stienstra  wrote:
> 
> On Mar 24, 2011, at 6:57 PM, Perry E. Metzger wrote:
> 
> > Would anyone who was previously involved in the maintenance of the
> > project explain what would be involved in a new set of people
> > maintaining the code base?
> 
> The blessed repository is on GitHub [1]. I'm sure Rich would love to accept 
> patches for the  from anyone who's interested in working on it.
> 
> Manfred
> 
> [1] https://github.com/richkilmer/hotcocoa
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
> 
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Is HotCocoa dead?

2011-03-25 Thread dan sinclair 
Sweet, didn't know about the automatic translation of objectForKey:. Will keep 
that in mind before wrapping it, heh. Are there any other methods to keep in 
mind that MacRuby automatically translates to a Ruby-ish version?

Thanks,
dan


On 2011-03-25, at 3:14 AM, Thibault Martin-Lagardette wrote:

> That's pretty cool :-).
> 
> Although "def [](key)" in nsuserdefaults_additions.rb seems to be 
> unnecessary, because macruby should already do that. It should automatically 
> replace [] and []= calls to objectForKey: and setObject:forKey: (when 
> necessary only, of course).
> I see you added deletion and sync on []=, which is why I didn't point it 
> being unnecessary :-)
> 
> 
> -- 
> Thibault Martin-Lagardette
> 
> On Friday, March 25, 2011 at 02:21, dan sinclair wrote:
> 
>> For me, I've basically dropped HotCocoa. After doing a few apps with it I 
>> quickly came to realize that I liked IB and building apps that way. The 
>> thing that I've missed from HotCocoa is all the little Ruby-ish extensions 
>> that it added to various classes. As I've built other apps I've been 
>> collecting up a few of those and decided to stuff them into a gem.
>> 
>> You can see them at https://github.com/dj2/Bean if you're interested.
>> 
>> Out of curiosity, what's the correct way to mark a gem as MacRuby only so I 
>> can push it up to rubygems.org?
>> 
>> dan
>> 
>> 
>> 
>> 
>> On Mar 24, 2011, at 8:56 PM, Matt Aimonetti wrote:
>> 
>>> Rich just sold his company to Living Social and I'm sure he's really busy 
>>> ATM.
>>> If people are willing to hack on this project and maintain it (the core 
>>> team won't), we probably should move it to its own repo and give commit 
>>> rights to people.
>>> 
>>> Who's interested in created a HotCocoa team?
>>> 
>>> Thanks,
>>> 
>>> - Matt
>>> 
>>> 
>>> On Thu, Mar 24, 2011 at 11:37 AM, Manfred Stienstra  
>>> wrote:
>>> 
>>> On Mar 24, 2011, at 6:57 PM, Perry E. Metzger wrote:
>>> 
>>>> Would anyone who was previously involved in the maintenance of the
>>>> project explain what would be involved in a new set of people
>>>> maintaining the code base?
>>> 
>>> The blessed repository is on GitHub [1]. I'm sure Rich would love to accept 
>>> patches for the from anyone who's interested in working on it.
>>> 
>>> Manfred
>>> 
>>> [1] https://github.com/richkilmer/hotcocoa
>>> ___
>>> MacRuby-devel mailing list
>>> [email protected]
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>> 
>>> ___
>>> MacRuby-devel mailing list
>>> [email protected]
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>> 
>> ___
>> MacRuby-devel mailing list
>> [email protected]
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
> 
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Is HotCocoa dead?

2011-03-25 Thread dan sinclair 
I was trying to keep the various forks in line for a while before I stopped 
working on HotCocoa. If you look at the network graph, there is a fork off of 
mine which I think contains everything that has been worked on so far. Maybe a 
good place to start synchronizing from.

dan



On 2011-03-24, at 10:57 PM, Matt Aimonetti wrote:

> Jordan, moving to GitHub helped but it also created fragmentation. Everyone 
> is working on its own fork and there is nobody to centralize all the changes 
> in a single repo.
> I agree that having a MacRuby based Processing like solution would be awesome.
> 
> - Matt
> 
> On Thu, Mar 24, 2011 at 7:35 PM, Jordan K. Hubbard  wrote:
> 
> On Mar 24, 2011, at 5:56 PM, Matt Aimonetti wrote:
> 
> > Rich just sold his company to Living Social and I'm sure he's really busy 
> > ATM.
> > If people are willing to hack on this project and maintain it (the core 
> > team won't), we probably should move it to its own repo and give commit 
> > rights to people.
> >
> > Who's interested in created a HotCocoa team?
> 
> I thought the project's being on GitHub facilitated this already?  You guys 
> should be able to start forking away and coordinating your patches over email 
> if there's any real interest in creating such a team!  I think it would be 
> interesting, myself, particularly if it led to the creation of something that 
> could compare to Processing. :)
> 
> - Jordan
> 
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
> 
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Is HotCocoa dead?

2011-03-25 Thread dan sinclair 
Cool, added. If you have others, feel free to fork and send me a pull request.

Thanks,
dan



On Mar 25, 2011, at 7:38 PM, Henry Maddocks wrote:

> 
> On 25/03/2011, at 2:21 PM, dan sinclair wrote:
> 
>> For me, I've basically dropped HotCocoa. After doing a few apps with it I 
>> quickly came to realize that I liked IB and building apps that way. The 
>> thing that I've missed from HotCocoa is all the little Ruby-ish extensions 
>> that it added to various classes. As I've built other apps I've been 
>> collecting up a few of those and decided to stuff them into a gem.
>> 
>> You can see them at https://github.com/dj2/Bean if you're interested.
> 
> 
> This is very good. I can see them being very useful.
> 
> Here's one I use a lot. Feel free to add it.
> 
> class NSIndexSet
> include Enumerable
> 
> def each
> i = self.firstIndex
> until i == NSNotFound
>yield i
>i = self.indexGreaterThanIndex(i)
> end
> end
> 
> end
> 
> 
> 
> Henry
> 
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] I don't normally plug the mailing list, but when I do it's for gemaholics

2011-06-20 Thread dan Sinclair 
I started a library of convenience wrappers for macruby  it's dj2/Bean
on github. Take a look and let me know what you think. Would love to
get more helpers in there.

Dan

On 2011-06-19, at 22:58, Joshua Ballanco  wrote:

> I was thinking more in the vein of HotCocoa as a library full of Cocoa 
> conveniences for MacRuby rather than HotCocoa as an Xcode replacement for app 
> development. I feel like Rich originally started HotCocoa figuring it would 
> replace Xcode, but I think that as time has progressed that is maybe a less 
> needed goal that was originally thought?
>
> Unfortunately, I have not had enough time to be as involved in HotCocoa as I 
> would have liked. There is certainly nothing wrong with keeping these as 
> independent gems. I do, however, think it might be useful to collect MacRuby 
> specific gems (especially those that make app development easier) in a 
> central list somewhere…
>
> - Josh
>
> On Sunday, June 19, 2011 at 7:17 PM, Robert Lowe wrote:
>
>> Thanks!
>>
>> I have not considered it. I think most developers are moving towards using 
>> MacRuby and Xcode 4.
>>
>> I don't see the need, maybe I'm misinformed. You can always just require 
>> them as needed.
>>
>> Can you think of a use case for it?
>>
>> Regards,
>> - Rob
>>
>> On 2011-06-19, at 7:10 PM, Joshua Ballanco wrote:
>>
>>> Very cool stuff, Rob!
>>>
>>> Have you considered potentially merging Hotkeys and mynu into HotCocoa?
>>>
>>> - Josh
>>>
>>> On Friday, June 17, 2011 at 3:09 PM, Robert Lowe wrote:
>>>
 Hi guys,

 Hope you enjoy em! All of these are on rubygems now:

 Wrapping NSMXL (Credit to Wilson Lee / kourge):
 https://github.com/RobertLowe/ayril

 Global Hotkeys:
 https://github.com/RobertLowe/hotkeys

 Systembar Menu DSL:
 https://github.com/RobertLowe/mynu

 It should be noted that these all work fine from inside xcode 4 too.

 If you find any edge cases let me know, I'll gladly take care of them. I'm 
 still new to the macruby community / cocoa.

 Transmission over,
 - Rob

 ___
 MacRuby-devel mailing list
 [email protected] 
 (mailto:[email protected])
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>>
>>>
>>> ___
>>> MacRuby-devel mailing list
>>> [email protected] 
>>> (mailto:[email protected])
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>
>> ___
>> MacRuby-devel mailing list
>> [email protected] 
>> (mailto:[email protected])
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
>
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] The future of MacRuby

2012-04-07 Thread dan sinclair 
Can we get the issues section enabled on github and move off of Trac? (Not
sure how hard it would be to import all of the old trac stuff to Github).

Would be nice to consolidate everything in one place.

dan



On Thu, Apr 5, 2012 at 3:06 PM, Matt Aimonetti wrote:

> *Many of you have been wondering what is going on with the MacRuby
> project given the lack of up-to-date releases and overall communication.
> I feel we owe you some explanation.
>
> As a lot of you have noticed, our de-facto project leader Laurent
> Sansonetti has been M.I.A since October 2011, his last post to this mailing
> list being
>
> http://lists.macosforge.org/pipermail/macruby-devel/2011-October/008168.htmlannouncing
>  MacRuby 0.11 really soon.
> His last commit was a change of license back in October:
> https://github.com/MacRuby/MacRuby/commit/ac2a7a8e678d19e44d3c64a9508a8370d082dca2
> 
> Laurent is fine. As described on his twitter http://twitter.com/lrz and
> LinkedIn http://www.linkedin.com/in/sansonetti accounts, Laurent is no
> longer with Apple and is clearly also no longer directly involved with the
> MacRuby project on a day-to-day basis.
> Laurent is currently busy with another project and and hopes to someday be
> able to contribute to the MacRuby project again.
>
> While no one on this list can speak for Apple, and Apple as a company does
> not tend to comment on its future plans or intentions, I think it's
> reasonable to imagine that Apple would be more than happy to have the
> MacRuby project decide for itself what its destiny is and how to achieve
> it.  If they did not want the community to be involved or drive such a
> process, they would not have released MacRuby as open source or created the
> project infrastructure to facilitate it.   It is time for us to stop
> looking to Apple to provide guidance, leadership and coding for the
> project, in other words, and take on those challenges for ourselves!
>   MacRuby is already very powerful and comparatively stable as a
> development platform, now it's time for us to take things to the next level.
>
> I personally think it will finally allow us to communicate and collaborate
> on the actual process of development as it occurs, rather than the previous
> practice of simply seeing code appear from some hidden, internal branch
> which was driven almost exclusively by a single person
>
> Doing all of this in the open should lead to far more people being
> interested in the project, not just as users but as developers and leaders.
>  No one rushes to fill a position that is occupied by someone else, but now
> we have a vacuum to fill, and that can be a good thing in terms of
> encouraging more people to step forward.
>
> Here is how I see things and I would love to hear more about what you guys
> think.
> MacRuby is a great project, but:
>
>- the target audience & projects aren't clear
>- the target platform (OS X) isn't the one we all really want to
>target (iOS)
>- Cocoa's API is awesome but not user friendly/easy to grasp
>
>
> What I'd like to suggest is the following:
>
> 1. Define clear goals for MacRuby that we can easily evaluate:
>
>- Focus primarily on making MacRuby the tool to use for quickly
>prototyping OS X and iOS applications.
>- Remove dependency on libauto so MacRuby can run post Mountain Lion
>and on iOS.
>
> 2. Increase the number of contributors:
>
>- Define areas of contribution:
>   - implementation itself (mainly requires C, C++ knowledge)
>   - prototyping focus (templates, wrapper APIs, modules, tools: a
>   full ecosystem aimed at being more productive)
>   - documentation (getting started, guides, FAQs, wiki, demos, hacker
>   guides)
>   - support
>
>
>- empower contributors:
>   - move the website to github for easier contribution
>   - better release process and roadmap
>   - better process to review pull requests & give commit rights
>
> 3. Improve communication:
>
>- start an active and official chat room (IRC, campfire like or
>something else)
>- open discussions about plans for the project and progress made
>- better collaboration with other Ruby implementation teams (Rubinius,
>JRuby, MagLev and of course Matz/C Ruby)
>
>
> Let's not forget that MacRuby is and will remain a free Open Source
> project and that means we need your help and support.
> Without you, this project doesn't mean much so please voice your opinion
> and if you decide to do so, become an active participant to MacRuby's
> success.
>
> I would like to thank Apple for their historical support and Laurent for
> starting this project and all his work so far. Without those contributions,
> MacRuby would never have existed and the project will more than welcome any
> future participation by either Apple or Laurent.
> At the same time, I don't think the future of this project can or should
> re

Re: [MacRuby-devel] The future of MacRuby

2012-04-07 Thread dan sinclair 
Can you import before it's open? I just assumed it wasn't accessible at all
until enable? It looks like forgeplucker (http://home.gna.org/forgeplucker/)
has support to pull tickets out of trac and dump to JSON. Should be pretty
easy to go from JSON to GitHub API I'd expect.

I can take a look and see what's involved.

dan




On Sat, Apr 7, 2012 at 2:40 PM, Eloy Duran  wrote:

> > Can we get the issues section enabled on github and move off of Trac?
> (Not sure how hard it would be to import all of the old trac stuff to
> Github).
> >
> > Would be nice to consolidate everything in one place.
>
> I think that’s an excellent idea. However, it’s probably better to first
> import tickets from Trac before we open it up for new tickets, because that
> won't leave any risk for damaging any tickets opened before the old tickets
> are imported and also avoids people spending time on duplicate tickets.
>
> Are you interested in investigating this?
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] The future of MacRuby

2012-04-09 Thread dan sinclair 
Jake,

Would you have time to continue with this effort, or should I continue
looking into the import?

Thanks,
dan



On Sun, Apr 8, 2012 at 9:00 AM, Jake Smith  wrote:

> I have already tried importing the tickets to GitHub at
> http://github.com/theviolentbear/macruby-issues using
> https://github.com/adamcik/github-trac-ticket-import. I was doing it so I
> could have offline access to tickets, but someone let me know that it was
> being discussed on the mailing list. It didn't properly escape code blocks
> nor did it import most of the metadata or respect the GitHub API limits,
> but it kind of worked as you can see.
>
> --
> Jake Smith
> pace e bene
>
> On Sunday, April 8, 2012 at 10:00 AM,
> [email protected] wrote:
>
> Send MacRuby-devel mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of MacRuby-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: The future of MacRuby (Eloy Duran)
> 2. Re: The future of MacRuby (dan sinclair)
>  3. Re: The future of MacRuby (Eloy Duran)
>
>
> --
>
> Message: 1
> Date: Sat, 7 Apr 2012 23:40:39 +0200
> From: Eloy Duran 
> To: "MacRuby development discussions."
> 
> Subject: Re: [MacRuby-devel] The future of MacRuby
> Message-ID: 
> Content-Type: text/plain; charset=windows-1252
>
> Can we get the issues section enabled on github and move off of Trac? (Not
> sure how hard it would be to import all of the old trac stuff to Github).
>
> Would be nice to consolidate everything in one place.
>
>
> I think that?s an excellent idea. However, it?s probably better to first
> import tickets from Trac before we open it up for new tickets, because that
> won't leave any risk for damaging any tickets opened before the old tickets
> are imported and also avoids people spending time on duplicate tickets.
>
> Are you interested in investigating this?
>
> --
>
> Message: 2
> Date: Sat, 7 Apr 2012 14:53:19 -0700
> From: dan sinclair 
> To: "MacRuby development discussions."
> 
> Subject: Re: [MacRuby-devel] The future of MacRuby
> Message-ID:
> 
> Content-Type: text/plain; charset="windows-1252"
>
> Can you import before it's open? I just assumed it wasn't accessible at all
> until enable? It looks like forgeplucker (
> http://home.gna.org/forgeplucker/)
> has support to pull tickets out of trac and dump to JSON. Should be pretty
> easy to go from JSON to GitHub API I'd expect.
>
> I can take a look and see what's involved.
>
> dan
>
>
>
>
> On Sat, Apr 7, 2012 at 2:40 PM, Eloy Duran 
> wrote:
>
> Can we get the issues section enabled on github and move off of Trac?
>
> (Not sure how hard it would be to import all of the old trac stuff to
> Github).
>
>
> Would be nice to consolidate everything in one place.
>
>
> I think that?s an excellent idea. However, it?s probably better to first
> import tickets from Trac before we open it up for new tickets, because that
> won't leave any risk for damaging any tickets opened before the old tickets
> are imported and also avoids people spending time on duplicate tickets.
>
> Are you interested in investigating this?
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.macosforge.org/pipermail/macruby-devel/attachments/20120407/5b4ccf1d/attachment-0001.html
> >
>
> --
>
> Message: 3
> Date: Sun, 8 Apr 2012 00:01:36 +0200
> From: Eloy Duran 
> To: "MacRuby development discussions."
> 
> Subject: Re: [MacRuby-devel] The future of MacRuby
> Message-ID: 
> Content-Type: text/plain; charset="windows-1252"
>
> Can you import before it's open? I just assumed it wasn't accessible at
> all until enable? It looks like forgeplucker (
> http://home.gna.org/forgeplucker