[chuck-users] code reusability

[mike clemow]

You make non-public classes, and the perl script basically appends those
classes to your script and creates a temporary file to send to the vm.

it's hacky, but it works.

#ifdef does NOT work.  only #include (myfile)

mike

2010/6/11 Andrew C. Smith <andrewchristophersmith at gmail.com>

> It's not clear to me--does #ifdef work? If not, you'd end up instantiating
> the same public class more than once.
>
> Also, a single file can only define one public class at a time, right? So,
> you'd have to spork a different shred for every class, and not just throw
> them all into one file. I may be misunderstanding the code though, because I
>  don't know Perl very well at all, and I'm preoccupied with something else
> right now.
>
> On Jun 11, 2010, at 1:50 PM, mike clemow wrote:
>
> Scott Wheeler's script is exactly that.  You should have a look.  The only
> thing is that it doesn't handle chuck command line args well.
>
> maybe some perl guru would be willing to have a go at modifying it.
>
> Mike
>
>
>
> 2010/6/11 Andrew C. Smith <andrewchristophersmith at gmail.com>
>
>> Hm, what about setting up some kind of python (or perl, etc...) script to
>> pre-process ChucK and handle all statements preceded by a #? So, you could
>> totally do the whole #IFDEF thing and make that work. That might be a
>> worthwhile library of stuff to do.
>>
>> Andrew
>>
>>
>> On Jun 11, 2010, at 12:08 PM, mike clemow wrote:
>>
>> Hey, I'd like to recall this thread:
>> https://lists.cs.princeton.edu/pipermail/chuck-users/2008-October/003408.html
>>
>> I used Scott Wheeler's chuck preprocessor (a Perl script) for a long time.
>>  I really liked the concept.  It did not work well with command line
>> arguments, however, the benefits as far as code-reuse were really nice.
>>  Obviously, things had to be imported in the correct order, but I think that
>> there might be a way around it, if each file you import also imported its
>> prerequisites.  IMHO, Chuck really needs something like this in order to
>> make a library a pleasure to use and a helpful thing to develop.
>>
>> LiCK would be trivial to use if Chuck had import/include statements built
>> in.  It's okay at the moment to do what Michael described above, i.e.:
>>
>> $ chuck --loop &
>> $ chuck + import.ck       // imports entire library
>> $ chuck + myChuckScript.ck
>>
>> on the command line, however, in miniAudicle, it's kind of annoying to
>> have to also open the import.ck file and run it before running any other
>> code.  You have to repeat all this when it crashes (which is something that
>> happens from time to time when developing new things ;).
>>
>> On the other hand, if I could just put:
>>
>> #include (LiCK);
>>
>> at the head of my code...  easy peasy.
>>
>> Or, if I only wanted part of LiCK imported:
>>
>> #include (FloatIterator);
>>
>> That's my buck-oh-five.
>>
>> Mike
>>
>>
>>
>>
>> On Fri, Jun 11, 2010 at 10:00 AM, Daniel Trueman <dtrueman at princeton.edu>wrote:
>>
>>> i believe in the next release you'll be able to open MIDI/Hid devices by
>>> name...
>>>
>>> On Jun 11, 2010, at 9:32 AM, Thomas Girod wrote:
>>>
>>> > Okay, that's pretty much what I did. Trying all the devices until I
>>> find
>>> > the one with the proper name is a good idea, thanks !
>>> >
>>> > Tom
>>> >
>>> > On Fri, Jun 11, 2010 at 02:08:38PM +0200, Kassen wrote:
>>> >> Hi Thomas!
>>> >>
>>> >> What I use for this kind of case (my Akai LPD8, for example) is a
>>> class with
>>> >> it's own sporked listener shred.
>>> >>
>>> >> At instantiation it could try to open all MIDI devices in turn, until
>>> the name
>>> >> of the device is whatever the name of your controller is. from there
>>> on you can
>>> >> add members and member functions that reflect whatever you want to do
>>> with the
>>> >> device, including a public event that other shreds could wait for. In
>>> the case
>>> >> of controllers with leds you'd probably also have member-functions
>>> that your
>>> >> code could use to set these, with your class handling the MIDI.
>>> >>
>>> >> If you build something like that once it will save you a lot of time
>>> in the
>>> >> long run and only having to do MIDI (with all of its magic numbers)
>>> once should
>>> >> make your coding a lot more pleasant. The class could sit in its own
>>> file (if
>>> >> you make it public), or you could simply copy and paste it to the
>>> bottom of
>>> >> your current project.
>>> >>
>>> >> Hope that helps?
>>> >> Kas.
>>> >
>>> > _______________________________________________
>>> > chuck-users mailing list
>>> > chuck-users at lists.cs.princeton.edu
>>> > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>
>>> _______________________________________________
>>> chuck-users mailing list
>>> chuck-users at lists.cs.princeton.edu
>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>
>>
>>
>>
>> --
>> http://michaelclemow.com
>> http://semiotech.org
>>
>>  _______________________________________________
>> chuck-users mailing list
>> chuck-users at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>
>>
>>
>> _______________________________________________
>> chuck-users mailing list
>> chuck-users at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>
>>
>
>
> --
> http://michaelclemow.com
> http://semiotech.org
>
>  _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>


-- 
http://michaelclemow.com
http://semiotech.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20100611/2f5b5b0b/attachment-0001.html>