On Apr 1, 2006, at 1:15 AM, Alexandre Quessy wrote:

Hi all,

I would like Gridflow to be part of Pd-extended on Mac OS X. We almost got to compile Gridflow on OSX 10.4. Mathieu told me that James Tittle has succeded in compiling Gridflow on OSX 10.3. As Gridflow is now self-contained in a single directory, it is now easier than ever to include it in a packaged distribution of pd-extended. Also, this would probably mean incuding Ruby 1.9 as well in the pd-extended package.

Ruby would need to be installed separately. Like using fink or apt- get. That's too much to put into the package. Python is also not included in Pd-extended tho [py] is.

That being said, there are still changes in Apple's Quartz API that makes the port to OSX 10.4 difficult. We are still getting errors when trying to compile it. Some fixes have been made to the CVS, but still, there are constants that have the same name than GF constants in Quartz. (or something like that, got to get back to the code to see exactly what) So, do you guys think that a GF version that has been compiled on OSX 10.3 would work on OSX 10.4 ? This could be a dirty solution to these littles bugs. Otherwise, let's keep chasing the name clashes.

Something compiled on 10.3.9 (.9 is important!) should work fine on 10.4, I don't think Apple broke things that badly. Things compiled on 10.4 generally work on 10.3.9 too.

Then, if we finally get it to work on OSX 10.4, would it be a problem to incude Ruby 1.9 in the package ? If so, it would mean that we would expect our users to install Ruby 1.9 from CVS in the command-line and to set their PATH accordingly. That's a bit ankward in my opinion.

Ruby really should be installed separately. There must be installer packages somewhere. Ruby 1.8 is already included in Mac OS X.

.hc

________________________________________________________________________ ____

"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore

On Sat, 1 Apr 2006, Alexandre Quessy wrote:

Also, this would probably mean incuding Ruby 1.9 as well in the pd-extended package.

I'm working on getting GridFlow to be something more easily binary-redistributable, and it means bundling Ruby with it.

We are still getting errors when trying to compile it. Some fixes have been made to the CVS, but still, there are constants that have the same name than GF constants in Quartz.

Hmmm, have you tried it again recently? Have you followed the thread on the gridflow-dev mailing-list? The changes I made with you at Vidéographe were not committed, so later I went through all of them again with James and fixed the last one that we hadn't fixed when you and I were at Vidéographe.

So, do you guys think that a GF version that has been compiled on OSX 10.3 would work on OSX 10.4 ?

Some differences between 10.3 and 10.4 affect only compilation (e.g. macro name clashes). Apart from that, I don't know but I don't think that there'd be much of a problem. I think James is running 10.4 nowadays.

Then, if we finally get it to work on OSX 10.4, would it be a problem to incude Ruby 1.9 in the package ?

It won't be a problem to include Ruby 1.9 (or part thereof) in the GridFlow packages, but that doesn't depend on the OS. I'll include Ruby on all platforms.

It turns out that not all Ruby 1.9 versions are created equal (some are more, er, equal than others). If I can make sure that everyone has got the same bugs... and also if I made changes to Ruby and I want people to use them... there are a lot of good reasons to switch to bundling Ruby.

If so, it would mean that we would expect our users to install Ruby 1.9 from CVS in the command-line and to set their PATH accordingly. That's a bit ankward in my opinion.

The new Makefile contains commands to download ruby-cvs automatically, but setting the PATH isn't done automatically yet... I might do that in 0.8.4.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada