Please tell about your projects Re: Fwd: Re: DIRECT version number

Very small snip (while preparing an answer for the whole thread):

On 7/19/2015 9:39 PM, Phil (list) wrote:
> ...
> communicated.  However, a problem I think he faces right now is that he
> doesn't know who's using / depending on what.
> ...

Yes. Cuis is MIT, etc. You don't have any obligations, etc.

But, if you tell what are you using Cuis for, and how, that is very
useful (and nice to know).
If you are maintaining a significant code base, if possible, tell about
it. This will help us better support you.

It is nice to know to what extent something you do is useful for others.
I think it is also a polite and reasonable way to say thanks to us,
working for you.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Juan,

On Thu, 2015-07-23 at 10:48 -0300, Juan Vuletich wrote:
(You wrote this first but I responded to it last... still couldn't get
it as short as I had hoped... :-)

Much of what I am currently doing in Cuis falls into the broad
categories of data processing, visualization/simulation and prototyping.

1) Data processing: Lots of importers and exporters.  The data I need is
all over the place both on my local filesystem/network as well as from
various Internet sources in just about every format you can imagine
whether it's munging some HTML if that's the only place I can find what
I need or processing some XML, SQLite, other text/binary data files (it
totally depends on the data source: whatever the source uses is what I'm
stuck with.  Additionally, I may need to emit a different format than I
took in.)  As a result, I've had to port a number of packages (some of
which I still maintain, others I've deprecated as things like FFI and
XML have become core Cuis packages) and write my own to support both
getting data into and back out of Cuis.  If all the task I'm doing
requires is data processing, this might be the end of the story: suck
the data in from whatever source/format, perform any needed processing,
and spit it back out to whatever destination/format.

2) Visualization/simulation: often I'm not just doing a simple data
conversion, so once the data is in Cuis I might need to do some analysis
to see what I'm dealing with, generate some charts/graphs, visualize
relationships within a data set or the results of a simulation, etc.
Sometimes it's tabular data, sometimes 2D image data, sometimes 3D,
sometimes temporal (tabular|2D|3D.) This is why I've got both Morphic
and OpenGL code lying around: for quick and easy 2D Morphic is hard to
beat, 3D and/or performance requirements push you to OpenGL.

3) Prototyping: most of the 'production' code I'm dealing with is in
other languages (Java for Android apps as an example). However, I find
non-dynamic languages unpleasant to prototype in.  So I find myself
quite often playing around with my ideas in Cuis even though the
implementation target might be a different language/environment.  This
is all over the place in terms of the 'what' (UI, networking, algorithm,
etc.)  Sometimes these prototypes often result in more code related to 1
and 2. Sometimes I decide that I could re-use whatever I was working on
in Cuis too, so I keep it.  Recently, I've started thinking a bit
differently about this one. (see 4)

1 and 2 almost always go together in some way.  3 is sometimes
standalone, but more and more it includes 1 and/or 2.  All together, I'd
estimate that the uses described above has resulted in about 100K LoC
across dozens of Cuis project files.  Lots of little things, depending
on lots of other little things.

An example of how this all fits together for me just using mostly core
Cuis packages for something you're probably quite familiar with:  I need
to do work on some SVG files.  No problem: XML parser can help there.
But they're out on a web site: easy, use Protocols-HTTP.  Parse the
file: now I depend on some of my framework code that depends on XML
parser since XML parser only deals with structure, not content.  Doh!
The SVG has embedded images: grab the compression and PNG support
(Graphics-File-Additional) packages.  Now the file is loaded and fully
parsed and you want to look at it: grab some Morphic code for that.
Need it to draw fast?  Use OpenGL + yet more framework code instead...
and OpenGL adds an FFI dependency.  So you've now got basic SVG support
with 8 packages and are ready to start doing the actual work which will
require additional packages.  This is both probably not impressive as it
might sound (it's only a subset of SVG, structured in a particular way)
and somewhat oversimplified (uses some custom extensions) but you get
the idea.  It's pretty clean and modular and things can pretty quickly
touch a couple dozen packages for a single task.  Most of my stuff is a
lot of this sort of thing. (i.e. a fair bit of work just to get the data
into a usable internal format. Once in, life gets easier until it's time
to export...)

Some future plans/projects:

4) As a result of spending more time with OMeta, I'm becoming convinced
that I can increase my usage beyond what I describe in 3: design and
build a prototype in Cuis and actually emit the code for the target
platform/environment.  With OMeta, code becomes just another data
source / target so why not? (minor detail of frameworks that I make
hand-wavy motions when reminded of... )  This is on my longer term wish
list and seems doable, it's just a lot of work to get there.  For things
like OpenGL/GPU compute it's looking to be a necessity.  For other
platform targets the payoff is less certain but this is interesting
enough that I don't care... I'll probably try to do it regardless of
whether or not it turns out to be a good idea :-)

5) For web apps, I've been finding Seaside quite nice to work with and
have been steadily increasing the things I'm using it for over the last
couple of years.  While this isn't yet Cuis related, it seems like there
are enough of us interested in something like this that at some point
we'll either figure out how to get Seaside ported or come up with
another solution.  At that point, Cuis will have permeated just about
every aspect of my development life :-)

> It is nice to know to what extent something you do is useful for others.
> I think it is also a polite and reasonable way to say thanks to us,
> working for you.
>

Absolutely.  That's also part of the reason I publish the packages I've
needed to port.  Life would have been so much simpler if someone had
taken care of that part so I didn't have to.  So, I push them out in the
hopes that it might save someone the trouble of having to deal with it
just as all of your efforts and others who have contributed to Cuis have
made my life easier.

> Cheers,
> Juan Vuletich

Thanks,
Phil


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

<quote author="Juan Vuletich-4">
Very small snip (while preparing an answer for the whole thread):

On 7/19/2015 9:39 PM, Phil (list) wrote:
> ...
> communicated.  However, a problem I think he faces right now is that he
> doesn't know who's using / depending on what.
> ...

Yes. Cuis is MIT, etc. You don't have any obligations, etc.

But, if you tell what are you using Cuis for, and how, that is very
useful (and nice to know).
If you are maintaining a significant code base, if possible, tell about
it. This will help us better support you.


How I want to use Cuis:

Multi-player games. Juan, are you going to put your Scrabble in a Cuis package?

App delivery sans IDE, halos, menus

Apps with feedback; output becomes next input

Recognition biometrics

Financial analysis

Anything fun

 - Dan

Thanks, folks.

(inline)
On 26/07/2015 07:47 p.m., Dan Norton wrote:
Uh, that was a long time ago... I guess it was around 1997 or 1998... It
would be fun to do it, though.

Cheers,
Juan Vuletich


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org