[Caml-list] ECSCW 2013: Call for Work-in-Progress

[Caml-list] ECSCW 2013: Call for Work-in-Progress

[Announce Announcements]

[-- Attachment #1: Type: text/plain, Size: 3893 bytes --]

::: ECSCW 2013 ::: Call for Work-in-Progress

The 13th European Conference on Computer Supported Cooperative Work (ECSCW 2013)

21-25 September 2013, Paphos, Cyprus

http://www.ecscw2013.org/

Work In Progress is a new peer reviewed submission category for ECSCW 2013.

The purpose of Work-in-Progress is to allow the community to participate in an
interactive event at ECSCW, where participants have an opportunity to present
and discuss their current work and early results. Work-in-Progress sessions
provide a unique opportunity for sharing valuable ideas, for getting early
feedback on current work and preliminary results, and fostering discussions
and collaborations among colleagues.

Work in progress papers will be published in ECSCW 2013 Proceedings Volume 2
(previously known as the conference supplement), printed in the Aarhus
University, Department of Computer Science Report Series and available for
the conference participants as well as on the EUSSET online library.


IMPORTANT DATES

·	Submission Deadline: 15 June 2013 (5:00pm PDT) using EasyChair
·	Notification Date: 26 July 2013
·	Camera-Ready Deadline: 09 August 2013


FORMAT

A Work-in-Progress submission is a six-page extended abstract prepared in
the ECSCW format (author kits and paper templates available for Word, PDF,
and LaTeX) and submitted as a PDF file, via the EasyChair submission system.

Your extended abstract should be camera-ready and thoroughly copy-edited.
Work-in-Progress submissions are not anonymous and should therefore include
all author names, affiliations and contact information.

Due to the short review cycle, there should be nearly no changes between
your submissions and the camera-ready final documents, except in rare
circumstances.


SELECTION PROCESS

Work-in-Progress submissions will be selected by the ECSCW Program Committee.
The process has been designed to acknowledge the early-stage nature of the work.
Work-in-Progress authors will be notified of acceptance. If a submission is
accepted to appear at the conference, the contact person will receive further
instructions regarding the inclusion of their extended abstract in the
Vol. 2 Proceedings, as well as instructions for the presentation at the conference.
Copyright is retained by the authors, and the material from them can be used as
the basis for future publications.


WHAT IS A WORK-IN-PROGRESS?

A Work-in-Progress is a concise report of recent findings or other types of
innovative or thought-provoking work relevant to the ECSCW community.  A
significant benefit of a Work-in-Progress derives from the discussion between
the author and conference attendees that will be fostered by the face-to-face
presentation of the work.

This submission category aims to attract participation from a broad range of
disciplines covering a spectrum of topics and methodologies. Submissions may
include, but are not limited to, the following types of work: description of
original CSCW systems, descriptions of new concepts, methods or techniques,
for use in CSCW, studies on collective practices, systems in use ...


AT THE CONFERENCE

Authors will be expected to attend the conference and will be assigned a time
and location in the program to present their work to conference attendees during
Interactive Sessions. Work-in-progress submissions whose authors are not at the
conference to present will be withdrawn from the EUSSET online library.


POSTER CHAIRS

Myriam Lewkowicz, Troyes University of Technology, France
Tommaso Colombino, Xerox Research Center, France

Contact: Ecscw2013wip@utt.fr



------------------------------------------------------
This is not SPAM. If you want to be removed from this list,
please send an email to [announce@cs.ucy.ac.cy] with the
single word 'remove' in the subject of the email.


[-- Attachment #2: Type: text/html, Size: 4615 bytes --]

[Caml-list] standard 3d vector library in OCaml

[Francois Berenger]

Hello,

Is there a standard library for this purpose?

Maybe I should relase mine, I have a small one.

Regards,
F.

Re: [Caml-list] standard 3d vector library in OCaml

[Florent Monnier]

2013/5/8, Francois Berenger:
> Hello,
>
> Is there a standard library for this purpose?
>
> Maybe I should relase mine, I have a small one.

I would enjoy to see your library.

Especially if some functions are usable for OpenGL.
Here is bellow what I'm using for OpenGL.
This is not a vector lib but a matrix lib tailored for use with
forward compatible OpenGL.
It only contains 2 or 3 (not-optimised) functions for vectors computations.

https://forge.ocamlcore.org/scm/viewvc.php/trunk/TEST3/ogl_matrix.mli?view=markup&revision=94&root=glmlite
https://forge.ocamlcore.org/scm/viewvc.php/trunk/TEST3/ogl_matrix.mli?view=markup&root=glmlite

https://forge.ocamlcore.org/scm/viewvc.php/trunk/TEST3/ogl_matrix.ml?view=markup&revision=94&root=glmlite
https://forge.ocamlcore.org/scm/viewvc.php/trunk/TEST3/ogl_matrix.ml?view=markup&root=glmlite

But this current revision 94 in the svn is not my more advanced version.
The more recent version is not in the svn because it's C code rewriten
in OCaml and the original code was provided under a more restrictive
license than the one of glMLite (MIT), and I don't want to downgrade
to (L)GPL.

Someone told me that I should not bother about this issue and that
this kind of code should be considered as only math.

http://www.linux-nantes.org/%7Efmonnier/ocaml/GL/fc/code/ogl_matrix.ml.xhtml
http://www.linux-nantes.org/%7Efmonnier/ocaml/GL/fc/code/

If your lib contains things useful for OpenGL I would be pleased to
integrate these parts in my module Ogl_matrix, or maybe even create a
new one Ogl_vector.
(But only if your license is MIT or similar)

-- 
Cheers

Re: [Caml-list] standard 3d vector library in OCaml

[Daniel Bünzli]

> 2013/5/8, Francois Berenger:
> > Hello,
> > 
> > Is there a standard library for this purpose?
It's not standard, unreleased and I hate to pre-announce but in the following months I plan to release Gg, a module that gives you basic types for 2D and 3D computer graphics; vectors, matrices, quaternions, axis-aligned boxes, colors and raster data.

Vectors and matrices are abstract but represented internally as records of floats. This allows to pass them directly to C functions that take double arrays and avoids bounds checking in OCaml code. The memory layout of matrices is also the one expected by OpenGL.

Except for the Raster module --- metadata for bigarrays to allow libraries to share raster data without depending on each other e.g. an OpenCV or image loading library and an OpenGL library --- the module is pretty stable now, it still needs a final code review though and one or two function names may change.

The current documentation of gg can be found here [1], the code can be browsed here [2]. It can also be installed via the erratique-unstable opam repo:

    opam repo add erratique-unstable http://erratique.ch/software/opam-unstable
    opam update 
    opam install gg

But I'd advise you not to that until the next release of opam because of this bug [3] which while harmless makes your `opam update` experience become unpleasant (you have to do a `opam remove gg`, before being able to `opam update`). 

Comments are welcome. 

Best,

Daniel


[1] http://erratique.ch/software/gg/doc/Gg.html
[2] https://github.com/dbuenzli/gg/
[3] https://github.com/OCamlPro/opam/issues/552

Re: [ocaml-opengl] [Caml-list] standard 3d vector library in OCaml

[Florent Monnier]

Hello Daniel,

2013/5/9, Daniel Bünzli:
>> 2013/5/8, Francois Berenger:
>> > Hello,
>> >
>> > Is there a standard library for this purpose?
>
> It's not standard, unreleased and I hate to pre-announce but in the
> following months I plan to release Gg, a module that gives you basic types
> for 2D and 3D computer graphics; vectors, matrices, quaternions,
> axis-aligned boxes, colors and raster data.

This is always christmas when you release something, thx :)

> Vectors and matrices are abstract but represented internally as records of
> floats. This allows to pass them directly to C functions that take double
> arrays and avoids bounds checking in OCaml code.

I found this trick in the ode bindings by Richard Jones.
In my opinion it's a good trick for matrices.
But I don't like it for xy or xyz triples. I prefer tuples for this
because it makes it more easy to exchange data between different ocaml
components and modules. For these I usually prefer something easy to
exchanges between different ocaml modules than something easy to
exchange with C. Because xy / xyz values are used a lot in the
high-level parts. And usually, in most parts of the code I use it
without open the tuple content, so the representation is not very
important except to make it easy to exchange without dependencies. So
this is why I prefer (float * float) and (float * float * float).

But this is only my taste. I don't know how other people manage this,
because there is not much code to read around for this kind of things.

>                                                   The memory layout of
> matrices is also the one expected by OpenGL.

It's great to have convenience like this.

> Except for the Raster module --- metadata for bigarrays to allow libraries
> to share raster data without depending on each other e.g. an OpenCV or image
> loading library and an OpenGL library ---

I've also started to play with OpenCV.
If you have things to share in OCaml I would enjoy to see it, even if
it's alpha.

>                                            the module is pretty stable now,
> it still needs a final code review though and one or two function names may
> change.

It looks quite close to a release.

> The current documentation of gg can be found here [1],

I appreciate the grey background.
With floaters in the eyes the darker is the better.
What is the license of your CSS, is it the same than your libs?
But if I build the docs from the sources it falls back to default
ocamldoc's css with plain white uncomfortable background.
Also how did you choosed this value of grey? Is it just your tastes,
or is it for a particular reason? I used very dark greys in the past
and some people sent me emails to ask me lighter background greys. Is
it compromise between people who like plain white and people who
prefer darker backgrounds?

>                                                        the code can be
> browsed here [2]. It can also be installed via the erratique-unstable opam
> repo:
>
>     opam repo add erratique-unstable
> http://erratique.ch/software/opam-unstable
>     opam update
>     opam install gg

Opam rules! [4]

> But I'd advise you not to that until the next release of opam because of
> this bug [3] which while harmless makes your `opam update` experience become
> unpleasant (you have to do a `opam remove gg`, before being able to `opam
> update`).
>
> Comments are welcome.

I noticed the mix functions for each types
mix x y t is the linear interpolation x +. t *. (y -. x)
It is not optimised for the case that we would apply it at each frame
and that (y -. x) will be the same all the time.
I have my own module for interpolation where it is not optimised too.
But I'm thinking to change it. Maybe some solution could be used to do
it in an elegant way that would not complicate the code too much.

Also you're providing only linear interpolation.
Is it that you're not using easing, or is it that you're using another
module for it?
If it's external I guess you're using the map functions to apply it.
I've started a small module for this, but I'm unsure what would be the
more convenient interface. Here are the interfaces of two different
snapshots:

http://www.linux-nantes.org/%7Efmonnier/ocaml/easing/doc-2013-04-05/Ease.html
http://www.linux-nantes.org/%7Efmonnier/ocaml/easing/doc-2013-04-05/Timed.html

http://www.linux-nantes.org/%7Efmonnier/ocaml/easing/doc-2013-05-09/Ease.html
http://www.linux-nantes.org/%7Efmonnier/ocaml/easing/doc-2013-05-09/Timed.html

Comments are wellcome.

Another thing that is only a question of taste, I would enjoy if there
would be aliases for the functions Size*.d w h with words entirely.
Sometimes the more readable is the shorter, some other times the
entire word will help understand what it is. So with aliases we can
choose what is the more pertinent for the situation.

Your new lib doesn't look promising, in fact it's already a must have!
(just like your other libs;)

> Best,
>
> Daniel
>
>
> [1] http://erratique.ch/software/gg/doc/Gg.html
> [2] https://github.com/dbuenzli/gg/
> [3] https://github.com/OCamlPro/opam/issues/552

[4] Well at least on Linux, in my Cygwin it doesn't work

--

Re: [ocaml-opengl] [Caml-list] standard 3d vector library in OCaml

[Daniel Bünzli]

Thanks for your comments. A few answers. 

> But I don't like it for xy or xyz triples. I prefer tuples for this
> because it makes it more easy to exchange data between different ocaml
> components and modules. For these I usually prefer something easy to
> exchanges between different ocaml modules than something easy to
> exchange with C. 


It's not only about C, it's also about avoiding boxed representations to reduce memory usage and provide more memory locality. I agree deconstructing these values is more painful than tuples but I hope this encourages you to perform computations vector-wise rather than coordinate-wise -- the implementation of gg does the latter so that its users can work as much as possible vector-wise with reasonable performance, falling back to coordinate-wise computations only in bottlenecks.

> I've also started to play with OpenCV.
> If you have things to share in OCaml I would enjoy to see it, even if
> it's alpha.


Nothing on that front. 
 
> I appreciate the grey background.


In my browser the background is white. In fact I now see that the background of the body is transparent in the stylesheet so that gray must be a default value in your browser...

> What is the license of your CSS, is it the same than your libs?
 
Yes feel free to reuse the stylesheet. Maintaining it is a little bit annoying as ocamldoc's markup tend to change from one version to the other and it's still hard to style because of formatting instructions in the markup and generation patterns that disallow you to distinguish certain case you'd like to (even with the deranged power of css). 

Myself I hope I can eventually drop that in favour of what is happening around opam doc in the OCaml platform [1]; provided they provide a sensitive stylesheet, which for me means reasonably dense vertically, not too wide horizontally and good use of white space instead of box disease -- blame the css border property for that.  

> But if I build the docs from the sources it falls back to default
> ocamldoc's css with plain white uncomfortable background.


Use ./build doc in the distribution to build with the stylesheet.
 
> Also you're providing only linear interpolation.
> Is it that you're not using easing, or is it that you're using another
> module for it?


For now I decided to leave that out of the library. I think there are many ways you'd like to do that depending on the context (e.g. see the links to shaping functions at the bottom of this page [2]). Since I was doubting I left it out. 

The goal of gg is also the keep a certain minimalism -- in fact I was even tempted to split the 2D from the 3D using the module language but eventually thought it was more consistant and less bureaucratic to have everything together.

> Another thing that is only a question of taste, I would enjoy if there
> would be aliases for the functions Size*.d w h with words entirely.
> Sometimes the more readable is the shorter, some other times the
> entire word will help understand what it is. So with aliases we can
> choose what is the more pertinent for the situation.


I dislike libraries that give aliases for the same things. It puts a useless cognitive burden on code readers which have to remember that there are two ways of naming the same thing and it results in inconsistant library usage style. I usually go with shorter names (sometimes too short I agree) because I like code compactness and stick to 80 columns.

Best,

Daniel

[1] http://www.cl.cam.ac.uk/projects/ocamllabs/tasks/platform.html#OPAM Doc (http://www.cl.cam.ac.uk/projects/ocamllabs/tasks/platform.html#OPAM%20Doc)
[2] http://www.flong.com/texts/code/

Re: [Caml-list] standard 3d vector library in OCaml

[Francois Berenger]

On 05/08/2013 11:32 AM, Francois Berenger wrote:
> Hello,
>
> Is there a standard library for this purpose?

By the way, I just saw in OPAM that there are bindings
to cairo, which looks quite nice for 2D vector graphics.

Re: [Caml-list] standard 3d vector library in OCaml

[rixed]

For what it's worth, I also did a small 2d vector library[1] some time ago in
order to learn some OCaml while doing something fun. What might be of interrest
is that it was able to read font outlines from truetype files, and some non
trivial triangulation algorithm was implemented. If someone is interrested it
could be a good thing to "port" this with this upcoming Gg lib (instead of my
own slower and certainly less elegant vector module).

[1]: http://gitorious.org/ocalme/geom

Re: [ocaml-opengl] [Caml-list] standard 3d vector library in OCaml

[Florent Monnier]

2013/5/10, Daniel Bünzli:
>> But I don't like it for xy or xyz triples. I prefer tuples for this
>> because it makes it more easy to exchange data between different ocaml
>> components and modules. For these I usually prefer something easy to
>> exchanges between different ocaml modules than something easy to
>> exchange with C.
>
> It's not only about C, it's also about avoiding boxed representations to
> reduce memory usage and provide more memory locality. I agree deconstructing
> these values is more painful than tuples but I hope this encourages you to
> perform computations vector-wise rather than coordinate-wise -- the
> implementation of gg does the latter so that its users can work as much as
> possible vector-wise with reasonable performance, falling back to
> coordinate-wise computations only in bottlenecks.

I do understand.
But what I was trying to explain is that I usually have 2 or 3 or even
more modules/components/libs each using 3D coordinates.
Then it is easy to exchange values that are (float * float * float).
Anything else makes things difficult for exchanges and needs to be converted.

>> I appreciate the grey background.
>
> In my browser the background is white. In fact I now see that the background
> of the body is transparent in the stylesheet so that gray must be a default
> value in your browser...

Indeed, your page is the first one I see with transparent background.
It is not recommended to define text color without background color.
If the default browser background color is black one would see nothing.

>> What is the license of your CSS, is it the same than your libs?
>
> Yes feel free to reuse the stylesheet. Maintaining it is a little bit
> annoying as ocamldoc's markup tend to change from one version to the other
> and it's still hard to style because of formatting instructions in the
> markup and generation patterns that disallow you to distinguish certain case
> you'd like to (even with the deranged power of css).

I know, this is the same for me.

> Myself I hope I can eventually drop that in favour of what is happening
> around opam doc in the OCaml platform [1]; provided they provide a sensitive
> stylesheet, which for me means reasonably dense vertically, not too wide
> horizontally and good use of white space instead of box disease -- blame the
> css border property for that.

I was thinking to group html api-docs of many libs together (and maybe
even keep all recent versions of the libs) with a css switcher
(probably hosted on the ocaml forge). I even thought about a name like
"ocamldoc-zen-garden" (inspired from "css-zen-garden"). What would you
think about such an idea?

>> Also you're providing only linear interpolation.
>> Is it that you're not using easing, or is it that you're using another
>> module for it?
>
> For now I decided to leave that out of the library. I think there are many
> ways you'd like to do that depending on the context (e.g. see the links to
> shaping functions at the bottom of this page [2]). Since I was doubting I
> left it out.

I would enjoy to know which of these you are considering.

[...]
> [2] http://www.flong.com/texts/code/

A very good link, thanks a lot!
There's a huge amount of content, could you share which you think
would be the more interesting for reuse in OCaml?

> The goal of gg is also the keep a certain minimalism -- in fact I was even
> tempted to split the 2D from the 3D using the module language but eventually
> thought it was more consistant and less bureaucratic to have everything
> together.

It seems logic to me to do it the way you've made it.
I would only comment that if you add Sizes, BBoxes, then why not also
bounding-cirlces / bounding-spheres, complete math for geometry with
points, lines, planes, etc. (distances, intersections, projections,
etc.)

The internal representations for vectors and points are not public,
which would imply to integrate these inside your module. Would you
accept pull requests for these, or you want to keep the current
minimalism?


> I dislike libraries that give aliases for the same things. It puts a useless
> cognitive burden on code readers which have to remember that there are two
> ways of naming the same thing and it results in inconsistant library usage
> style. I usually go with shorter names (sometimes too short I agree) because
> I like code compactness and stick to 80 columns.

Maybe a compromise could be found,
between one letter function names:

Size3.w
Size3.h
Size3.d

and complete names:

Size3.width
Size3.height
Size3.depth

could be 3 letters abbreviations:

Size3.wid
Size3.hei
Size3.dep

I would recommend not to assume that everyone share the same cognition
and tastes than you.

-- 
Regards

Re: [ocaml-opengl] [Caml-list] standard 3d vector library in OCaml

[Daniel Bünzli]

Le vendredi, 10 mai 2013 à 16:48, Florent Monnier a écrit :

> A very good link, thanks a lot!
> There's a huge amount of content, could you share which you think
> would be the more interesting for reuse in OCaml?

I think each of them serve different purpose (e.g. computational trade-offs on embedded platforms) that's the reason why these things are best left outside gg for now.  

> It seems logic to me to do it the way you've made it.
> I would only comment that if you add Sizes, BBoxes, then why not also
> bounding-cirlces / bounding-spheres, complete math for geometry with
> points, lines, planes, etc. (distances, intersections, projections,
> etc.)

I don't plan to integrate these things, no pull requests please. At a certain point I was planning to but it was becoming unwieldy -- remnant of these ideas can be seen in the tmp/ directory of the first commit. Gg provides you with the essentials to do 2D or 3D computer graphics. Sizes and rectangles are ubiquitous: viewports, image extents, etc. and that's the reason they are in. More general computational geometry tools are best left to another dedicated library.
  
> The internal representations for vectors and points are not public,
> which would imply to integrate these inside your module.

Regarding the internal representation I still have to think about what I will do. Gg is designed to interoperate with C so that means that the representation will be cast in stone anyways.

> Maybe a compromise could be found,
> between one letter function names:
>  
> Size3.w
> Size3.h
> Size3.d
>  
> and complete names:
>  
> Size3.width
> Size3.height
> Size3.depth
>  
> could be 3 letters abbreviations:
>  
> Size3.wid
> Size3.hei
> Size3.dep

Well, no… it's horrible to read, hard to remember and inconsistent: if you look at all the other vector types in Gg their coordinate accessors all have a single letter V2.{x,y}, P2.{x,y}, V3.{x,y,z}, P3.{x,y,z}, V4.{x,y,z,w}, Color.{r,g,b,a}, Quat.{x,y,z,w}. Having Size2.{w,h} and Size3.{w,h,d} feels natural.  

> I would recommend not to assume that everyone share the same cognition
> and tastes than you.

I certainly don't assume that. I do however program and design to my taste, not by consensus or compromise.

Best,

Daniel

Re: [ocaml-opengl] [Caml-list] standard 3d vector library in OCaml

[Anthony Tavener]

[-- Attachment #1: Type: text/plain, Size: 3197 bytes --]

I've found that using a module prefix in combination with short (single
letter) labels in mathematical contexts works very well. It strikes a
balance of succinctness-in-use with enough verbosity to establish context.
So I like Daniel's field names. :) They also correspond to shading language
field designations. Before local module-opens I would avoid such names
because opening more than one module would almost guarantee a conflict. Now
I only open a few "prevasives"-like modules and use local-opens liberally.



On Fri, May 10, 2013 at 11:01 AM, Daniel Bünzli <daniel.buenzli@erratique.ch
> wrote:

>
>
> Le vendredi, 10 mai 2013 à 16:48, Florent Monnier a écrit :
>
> > A very good link, thanks a lot!
> > There's a huge amount of content, could you share which you think
> > would be the more interesting for reuse in OCaml?
>
> I think each of them serve different purpose (e.g. computational
> trade-offs on embedded platforms) that's the reason why these things are
> best left outside gg for now.
>
> > It seems logic to me to do it the way you've made it.
> > I would only comment that if you add Sizes, BBoxes, then why not also
> > bounding-cirlces / bounding-spheres, complete math for geometry with
> > points, lines, planes, etc. (distances, intersections, projections,
> > etc.)
>
> I don't plan to integrate these things, no pull requests please. At a
> certain point I was planning to but it was becoming unwieldy -- remnant of
> these ideas can be seen in the tmp/ directory of the first commit. Gg
> provides you with the essentials to do 2D or 3D computer graphics. Sizes
> and rectangles are ubiquitous: viewports, image extents, etc. and that's
> the reason they are in. More general computational geometry tools are best
> left to another dedicated library.
>
> > The internal representations for vectors and points are not public,
> > which would imply to integrate these inside your module.
>
> Regarding the internal representation I still have to think about what I
> will do. Gg is designed to interoperate with C so that means that the
> representation will be cast in stone anyways.
>
> > Maybe a compromise could be found,
> > between one letter function names:
> >
> > Size3.w
> > Size3.h
> > Size3.d
> >
> > and complete names:
> >
> > Size3.width
> > Size3.height
> > Size3.depth
> >
> > could be 3 letters abbreviations:
> >
> > Size3.wid
> > Size3.hei
> > Size3.dep
>
> Well, no… it's horrible to read, hard to remember and inconsistent: if you
> look at all the other vector types in Gg their coordinate accessors all
> have a single letter V2.{x,y}, P2.{x,y}, V3.{x,y,z}, P3.{x,y,z},
> V4.{x,y,z,w}, Color.{r,g,b,a}, Quat.{x,y,z,w}. Having Size2.{w,h} and
> Size3.{w,h,d} feels natural.
>
> > I would recommend not to assume that everyone share the same cognition
> > and tastes than you.
>
> I certainly don't assume that. I do however program and design to my
> taste, not by consensus or compromise.
>
> Best,
>
> Daniel
>
>
> _______________________________________________
> OpenGL mailing list
> OpenGL@lists.ocaml.org
> http://lists.ocaml.org/listinfo/opengl
>

[-- Attachment #2: Type: text/html, Size: 4001 bytes --]

Re: [Caml-list] standard 3d vector library in OCaml

[Francois Berenger]

On 05/08/2013 10:55 PM, Florent Monnier wrote:
> 2013/5/8, Francois Berenger:
>> Hello,
>>
>> Is there a standard library for this purpose?
>>
>> Maybe I should relase mine, I have a small one.
>
> I would enjoy to see your library.

It's in OPAM now under the name vector3.

Regards,
F.