> it just composes pixmaps into OpenGL textures.
in case there would be Xlib/openGL hackers interested by this technique
which is explained here for C:
http://www.opengl.org/wiki/index.php/Programming_OpenGL_in_Linux:_Creating_a_texture_from_a_Pixmap
it can be achieved in OCaml too, this demo pro
On Saturday 15 November 2008 12:25:17 Richard Jones wrote:
> On Sat, Nov 15, 2008 at 01:02:53PM +, Jon Harrop wrote:
> > ...design that centers around a single unified renderer and unified
> > (and safe!) representation ...
>
> Huh? Guess you've not used compiz then?
Compiz does not provide a
On Sat, Nov 15, 2008 at 01:02:53PM +, Jon Harrop wrote:
> http://video.msn.com/video.aspx?vid=0bcf031b-4213-48ef-adff-0e60f8dbce4b
>
> Linux has nothing like this.
Huh? Guess you've not used compiz then? Linux has had it since
before 2005 and it's so annoying I always turn it off.
Rich.
We were discussing GUI programming in OCaml recently. I just stumbled upon
this video "wpf graphics" that demonstrates some of the capabilities of
Microsoft's Windows Presentation Foundation:
http://video.msn.com/video.aspx?vid=0bcf031b-4213-48ef-adff-0e60f8dbce4b
Linux has nothing like this
On Wednesday 05 November 2008, Jérémie Dimino wrote:
> Jon Harrop <[EMAIL PROTECTED]> writes:
> > I'd forget about that and just focus on making the whole of Qt4 available
> > safely from OCaml in any form first. Even this is an unsolved problem in
> > the OCaml world!
>
> I suggest an idea. I know
> > And neither QPainterPath nor QPicture are really hierarchical. About the
> > only way to think of a hierarchy for Qt's drawing system is at the level
> > of QPainter, which provides save() / restore() functionality for its
> > state. All of this structure is implemented by the QPainter(), so as
On Wednesday 05 November 2008 16:33:43 Jérémie Dimino wrote:
> Jon Harrop <[EMAIL PROTECTED]> writes:
> > I'd forget about that and just focus on making the whole of Qt4 available
> > safely from OCaml in any form first. Even this is an unsolved problem in
> > the OCaml world!
>
> I suggest an idea
On Wednesday 05 November 2008 17:08:21 Jon Harrop wrote:
> Smoke already runs fine using Mesa and Mesa is still seeing huge
> performance improvements, e.g. using run-time generated code via LLVM. If
> you desperately needed Smoke on an embedded platform, I would just port it
> to OpenGL ES instead
Jon Harrop <[EMAIL PROTECTED]> writes:
> I'd forget about that and just focus on making the whole of Qt4 available
> safely from OCaml in any form first. Even this is an unsolved problem in the
> OCaml world!
I suggest an idea. I know that Qt4 offer some facility to export
objects trough DBus
On Wednesday 05 November 2008 15:55:24 Kuba Ober wrote:
> Would it be useful, then, to have Smoke have a built-in renderer for
> embedded/non-accelerated platforms? It should still be faster than Mesa,
> since you can work with higher-level objects that can perhaps be drawn
> faster with object-spe
On Wednesday 05 November 2008 15:44:24 Kuba Ober wrote:
> And neither QPainterPath nor QPicture are really hierarchical. About the
> only way to think of a hierarchy for Qt's drawing system is at the level of
> QPainter, which provides save() / restore() functionality for its state.
> All of this s
On Wednesday 05 November 2008, Jon Harrop wrote:
> On Wednesday 05 November 2008 15:20:26 Kuba Ober wrote:
[snip]
> > So, please understand that I'm not oblivious to benefits of thinking in
> > higher levels of abstraction, but I'm also practical and know that Qt
> > provides me with a whole big lo
On Wednesday 05 November 2008 15:05:13 Kuba Ober wrote:
> > However, Trolltechs own demos segfault on my machine regularly
> > and KDE is unreliable despite being written almost entirely in Qt's
> > native language. So I would not be so hasty to blame PyQt for Qt's
> > reliability problems.
>
> As
On Wednesday 05 November 2008 08:39:32 Paolo Donadeo wrote:
> > In contrast, you can implement a GUI toolkit in OCaml that far exceeds
> > the relevant limitations of Qt4 with quite easily.
>
> Jon, did you ever used Qt in a big C++ or Python project? Qt is the
> best GUI framework out there, GTK i
On Wednesday 05 November 2008, Paolo Donadeo wrote:
> > In contrast, you can implement a GUI toolkit in OCaml that far exceeds
> > the relevant limitations of Qt4 with quite easily.
>
> Jon, did you ever used Qt in a big C++ or Python project? Qt is the
> best GUI framework out there, GTK is a ridi
On Wednesday 05 November 2008 15:20:26 Kuba Ober wrote:
> > > Have you ran recent Qt demos distributed with Qt? I'd say they look
> > > pretty cool in my book.
> >
> > They would not have impressed me a decade ago, let alone today. Many of
> > them don't even work on either of my Debian machines.
>
> > Have you ran recent Qt demos distributed with Qt? I'd say they look
> > pretty cool in my book.
>
> They would not have impressed me a decade ago, let alone today. Many of
> them don't even work on either of my Debian machines.
I have one question regarding OpenGL: maybe it's just me, but isn'
> However, Trolltechs own demos segfault on my machine regularly
> and KDE is unreliable despite being written almost entirely in Qt's native
> language. So I would not be so hasty to blame PyQt for Qt's reliability
> problems.
As a longtime KDE user, I'm very much disappointed by the most recent
On Wednesday 05 November 2008, Jon Harrop wrote:
> On Tuesday 04 November 2008 23:06:00 Kuba Ober wrote:
> > On Tuesday 04 November 2008, Jon Harrop wrote:
> > > You'll just be invoking autogenerated Python code using OCaml so
> > > OCaml's class system is only relevant if you want to do some fancy
On Wednesday 05 November 2008 08:53:28 Paolo Donadeo wrote:
> > No, you just invoke the existing Python bindings. OCaml doesn't have to
> > implement anything except bindings to Python, which are already done.
>
> From this sentence I deduce you don't know *how* the PyQt binding is
> generated. It'
> No, you just invoke the existing Python bindings. OCaml doesn't have to
> implement anything except bindings to Python, which are already done.
>From this sentence I deduce you don't know *how* the PyQt binding is
generated. It's not a trivial task and the binding layer adds it's own
bugs and gl
> In contrast, you can implement a GUI toolkit in OCaml that far exceeds the
> relevant limitations of Qt4 with quite easily.
Jon, did you ever used Qt in a big C++ or Python project? Qt is the
best GUI framework out there, GTK is a ridiculous toy in comparison,
and it took ages to reach this leve
On Tuesday 04 November 2008 23:06:00 Kuba Ober wrote:
> On Tuesday 04 November 2008, Jon Harrop wrote:
> > You'll just be invoking autogenerated Python code using OCaml so OCaml's
> > class system is only relevant if you want to do some fancy
> > statically-typed shim. I'd forget about that and jus
On Tuesday 04 November 2008, Jon Harrop wrote:
> On Tuesday 04 November 2008 18:35:45 Kuba Ober wrote:
> > On Monday 03 November 2008, Jon Harrop wrote:
> > > On Monday 03 November 2008 14:15:38 Kuba Ober wrote:
> > > > I could port Camelia to OCaml if
> > > > someone would first develop Qt binding
On Tuesday 04 November 2008 18:35:45 Kuba Ober wrote:
> On Monday 03 November 2008, Jon Harrop wrote:
> > On Monday 03 November 2008 14:15:38 Kuba Ober wrote:
> > > I could port Camelia to OCaml if
> > > someone would first develop Qt bindings for OCaml that would allow me
> > > to do in OCaml what
On Monday 03 November 2008, Jon Harrop wrote:
> On Monday 03 November 2008 14:15:38 Kuba Ober wrote:
> > On Friday 31 October 2008, Jon Harrop wrote:
> > > . Written in OCaml using OCaml's own lexer and parser to save effort
> > > and make it possible for others to help develop it without losing th
On Monday 03 November 2008 14:15:38 Kuba Ober wrote:
> On Friday 31 October 2008, Jon Harrop wrote:
> > . Written in OCaml using OCaml's own lexer and parser to save effort and
> > make it possible for others to help develop it without losing their hair.
>
> That's perhaps possible in the longer ru
On Friday 31 October 2008, Jon Harrop wrote:
> On Monday 20 October 2008 14:19:40 Kuba Ober wrote:
> > what do you guys use for your development environment?
>
> I use Emacs but I hate it.
:)
> > What would be the minimal set of functionality that would make you happy
> > for an IDE?
>
> . Written
On Monday 20 October 2008 14:19:40 Kuba Ober wrote:
> what do you guys use for your development environment?
I use Emacs but I hate it.
> What would be the minimal set of functionality that would make you happy for
> an IDE?
. Written in OCaml using OCaml's own lexer and parser to save effort an
Daniel Bünzli wrote:
>
> Le 26 oct. 08 à 01:08, Martin Jambon a écrit :
>
>> In performance-critical code or maybe imperative code in general, it
>> feels good to control when closures are created. In such cases, avoiding
>> local functions helps.
>
> Just to be clear, naming your anonymous func
Le 26 oct. 08 à 01:08, Martin Jambon a écrit :
In performance-critical code or maybe imperative code in general, it
feels good to control when closures are created. In such cases,
avoiding
local functions helps.
Just to be clear, naming your anonymous function locally (which is
what is r
Daniel Bünzli wrote:
>
> Le 25 oct. 08 à 14:43, Martin Jambon a écrit :
>
>> Now I generally tend to use this:
>>
>> let x =
>> List.map (
>>fun z ->
>> very_blabla
>> ...
>> ) my_list
>> in
>
> I think the best solution is to name your anonymous function, as the
> guidelines sug
Le 25 oct. 08 à 14:43, Martin Jambon a écrit :
Now I generally tend to use this:
let x =
List.map (
fun z ->
very_blabla
...
) my_list
in
I think the best solution is to name your anonymous function, as the
guidelines suggest [1].
Regards,
Daniel
[1]
http://caml.inria.fr
DooMeeR wrote:
> Another possibility is:
>
> let x = List.map begin fun z ->
> very_blabla
> end my_list in
>
> It's quite compact, doesn't run into the margin, is consistent with
> tuareg, but might be less readable.
Now I generally tend to use this:
let x =
List.map (
fun z ->
ve
Using labels makes this kind of code more readable.
open StdLabels
let x = List.map my_list ~f:
begin fun z ->
very_blabla
end in
...
Jacques Garrigue
From: DooMeeR <[EMAIL PROTECTED]>
> Another possibility is:
>
> let x = List.map begin fun z ->
> very_blabla
> end my_l
Another possibility is:
let x = List.map begin fun z ->
very_blabla
end my_list in
It's quite compact, doesn't run into the margin, is consistent with
tuareg, but might be less readable.
--
Romain Bardou
Dave Benjamin a écrit :
Romain Bardou wrote:
let x = List.map (fun z ->
On Thu, 23 Oct 2008 15:53:19 +0200
"Baudet David" <[EMAIL PROTECTED]> wrote:
> > I agree. There are many different use cases, different types of developers
> > with different goals and styles. Putting most of the heavy lifting into
> > external tools so that can be integrated into any editor wou
On Thursday 23 October 2008, Vincent Hanquez wrote:
> On Thu, Oct 23, 2008 at 12:01:00PM +0100, Hugo Ferreira wrote:
> > Thomas Gazagnaire wrote:
> >> I would prefer to not have an editor which modify completely the file I
> >> am working on (ie. automatically replace tab by spaces). When working
>
> >> What would make me switch: a way to highlight the error when compiling,
> >> highlighting the line, a stronger highlight for the character range
> >> reported by the compiler, taking in consideration the tab mode used
> >> (real tab, n spaces) to interpret the value returned by the compiler.
>
On Wednesday 22 October 2008, you wrote:
> Thanks, I tried it and I love the simplicity vis-a-vis eclipse's
> baroqueness. But am I missing something?
> When I type in a line of caml followed by a CR the cursor lines up all
> the way to the left rather than indenting
> on the next line. Once I'm do
Romain Bardou wrote:
let x = List.map (fun z ->
very_long_stuff_blablablablablablablabla)
I tend to write this sort of thing as:
let x =
List.map
(fun z ->
very_long_stuff_blablablablablablablabla)
...
which, as you may notice, still can't be done with tab
tab has no length. projects tab-indented (not talking about alignment here),
is the only consistant choice that permit everyone in this same project
to use any *representation* they want for their indentation (8 spaces, 2
spaces, 4 spaces, 11 spaces, ...) without making a mess.
Sure, this would
On Thu, Oct 23, 2008 at 12:01:00PM +0100, Hugo Ferreira wrote:
> Thomas Gazagnaire wrote:
>> I would prefer to not have an editor which modify completely the file I
>> am working on (ie. automatically replace tab by spaces). When working
>> on big project, you cannot assume that everybody use spa
> I agree. There are many different use cases, different types of developers
> with different goals and styles. Putting most of the heavy lifting into
> external tools so that can be integrated into any editor would be a great
> boon across the board.
>
> Actually, how did ocamlwizard go? I seem
Thomas Gazagnaire wrote:
I would prefer to not have an editor which modify completely the file I
am working on (ie. automatically replace tab by spaces). When working on
big project, you cannot assume that everybody use spaces-based editor,
and you still want to minimize the diff size of your p
I would prefer to not have an editor which modify completely the file I am
working on (ie. automatically replace tab by spaces). When working on big
project, you cannot assume that everybody use spaces-based editor, and you
still want to minimize the diff size of your patches.
Thomas
2008/10/23 R
That's actually nearly what Camelia has right now. Right now Camelia
insists on not dealing with tabs at all -- it converts them all to
spaces. This "feature" has to go obviously, and it's a few-liner to
convert between characters (which include tabs) and columns.
What do you mean with this? Rea
Hello,
Kuba Ober wrote:
What would make me switch: a way to highlight the error when compiling,
highlighting the line, a stronger highlight for the character range
reported by the compiler, taking in consideration the tab mode used (real
tab, n spaces) to interpret the value returned by the comp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tuesday 21 October 2008 03:31:26 pm Till Varoquaux wrote:
> There is a mix of Emacs,vim,texmate and other esoteric editors being
> used here. We are all free to choose what we use but I think a lot of
> us decide to cope with a steeper learning curv
Le me be more specific: we're not working on a ocamlbrowser replacement.
We're just working on a on-line help system. In turn, this help system
could be useful for someone wishing to write a ocamlbrowser replacement.
Cheers,
David
On Wed, 2008-10-22 at 23:56 +0200, David Teller wrote:
> For info
On Wed, 2008-10-22 at 08:42 -0400, Kuba Ober wrote:
> > An integrated ocamlbrowser (the standard TK tend to jiggle and hang on my
> > computer).
>
> OK, I'm adding this to my feature list. I didn't even know ocamlbrowser
> existed (never quite made it through the manual, I'm afraid).
For informat
> What would make me switch: a way to highlight the error when compiling,
> highlighting the line, a stronger highlight for the character range
> reported by the compiler, taking in consideration the tab mode used (real
> tab, n spaces) to interpret the value returned by the compiler.
> the error m
Hello,
I'm somewhat ashamed of myself, but I must confess: I'm one of those wimps
using texmate! ;-)
I like the long time spent in front of it without my eyes being too tired
(mostly due
to the good mac font antialiasing), the set of color scheme, support for ocaml.
What would make me switch: a
I am answering as someone who works at jane street but not for jane
street (i.e. this is my personal point of view but I am a Jane street
employee).
First of all thank you for tackling the IDE problem. Anything that's
good for the Ocaml community is, by osmosis, good for companies
working with Oca
> > I really like OcaIDE (http://ocaml.eclipse.ortsa.com:8480/ocaide/).
> > It's Eclipse plugin so Windows is fully supported (including graphical
> > debugging). IMHO it's (almost) ready for commercial development. Many
> > features are very convenient: hyperlink jumps, code outline, type
> > tool
(I know it's off-topic, but anyway...)
You should be happy to find out about Yi, an editor written in Haskell:
http://www.haskell.org/haskellwiki/Yi
On Mon, Oct 20, 2008 at 05:02:46PM -0600, Robert Morelli wrote:
...
> PS: Almost exactly the same pattern of poor quality and glacially slo
Dmitry Bely wrote:
On Mon, Oct 20, 2008 at 5:19 PM, Kuba Ober <[EMAIL PROTECTED]> wrote:
I have questions to the kind folks at Jane Street,
and others who use OCaml for commercial/non-research
development: what do you guys use for your development
environment? What would be the minimal set of fu
On Mon, Oct 20, 2008 at 5:19 PM, Kuba Ober <[EMAIL PROTECTED]> wrote:
> I have questions to the kind folks at Jane Street,
> and others who use OCaml for commercial/non-research
> development: what do you guys use for your development
> environment? What would be the minimal set of functionality
>
Hi,
and there is of course Yi[1], although it is written in Haskell.
[1] http://www.haskell.org/haskellwiki/Yi
Regards,
Jean-Marie
David Teller wrote:
> Just for the sake of bibliography, this reminds me of efuns [1] and
> Chamo [2].
>
> [1] http://pauillac.inria.fr/cdrom/prog/unix/efuns/eng
Robert Morelli schrieb:
> The emacs tags system didn't work for you?
There is no way to produce tags files for emacs that does actually work, no?
exuberant-ctags doesn't support caml, otags is still on 3.09 and ocamltags
doesn't understand files in directories...
Am I missing something?
- Floria
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Monday 20 October 2008 07:02:46 pm Robert Morelli wrote:
> Because of its poor design, I lost the heart to try to program complex
> tasks in Emacs lisp quite
> a while ago, so I don't have everything fresh in my mind. Perhaps Peng
> Zang who posted
Richard Jones wrote:
On Mon, Oct 20, 2008 at 09:45:34AM -0600, Robert Morelli wrote:
What Emacs lisp does wrong is virtually a checklist of bad programming
language design. On the
other hand, these are all of the things languages like OCaml do right.
It'd be interesting to hear[1] wha
On Mon, 20 Oct 2008 13:15:52 -0400
Yitzhak Mandelbaum <[EMAIL PROTECTED]> wrote:
> On Oct 20, 2008, at 11:56 AM, David Teller wrote:
> >
> > Just for the sake of bibliography, this reminds me of efuns [1] and
> > Chamo [2].
> >
> > [1] http://pauillac.inria.fr/cdrom/prog/unix/efuns/eng.htm
> > [2]
> It'd be interesting to hear[1] what exact features of elisp are
> counterproductive for large-scale collaborative programming.
>
> I've not looked very closely at elisp, but assumed the reason that
> emacs remains "unconfigurable" for most users is because it's Lisp,
> not because of the particul
On Monday 20 October 2008, you wrote:
> > What are killer features you dream of?
>
> Clearly, the ability to click on a function to go to the place where it is
> defined is the only reason why I switched from emacs to Eclipse
I think that Camelia can do that -- it already fetches type annotations
On Mon, Oct 20, 2008 at 09:45:34AM -0600, Robert Morelli wrote:
> What Emacs lisp does wrong is virtually a checklist of bad programming
> language design. On the
> other hand, these are all of the things languages like OCaml do right.
It'd be interesting to hear[1] what exact features of elisp a
> I use 16 (4x4) virtual Fvwm desktops with free mouse movement between
> them and a small map of the desktops in the lower-right corner (+
> xosview). The majority of the population finds this disturbing, I'm not
> really sure why. I hate clicking or typing to switch from a window to
> another so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have written smart autocompletion based on the toplevel in a mode I call
SOLID.
http://www.cc.gatech.edu/~pengzang/tools.html
I've never gotten around to announcing it because it takes time to polish up
and write good doc... time that I haven't
On Oct 20, 2008, at 11:56 AM, David Teller wrote:
Just for the sake of bibliography, this reminds me of efuns [1] and
Chamo [2].
[1] http://pauillac.inria.fr/cdrom/prog/unix/efuns/eng.htm
[2] http://home.gna.org/cameleon/
Cheers,
David
Does anyone know the status of either of these projects?
On Mon, 2008-10-20 at 09:45 -0600, Robert Morelli wrote:
> So, my dream would be for someone to build a text editor with the same
> basic philosophy as Emacs,
> cloning a good bit of its core functionality, but built on a sound
> architecture, and capable of dealing with
> the demands of modern c
Thomas Gazagnaire wrote:
> What are killer features you dream of?
Clearly, the ability to click on a function to go to the place where
it is defined is the only reason why I switched from emacs to Eclipse
... And I would be very happy to switch to a faster IDE because
Eclipse is so slow on b
Kuba Ober wrote:
> I have questions to the kind folks at Jane Street,
> and others who use OCaml for commercial/non-research
> development: what do you guys use for your development
> environment? What would be the minimal set of functionality
> that would make you happy for an IDE? What are killer
On Oct 20, 2008, at 9:37 AM, Mark Shinwell wrote:
On Mon, Oct 20, 2008 at 09:19:40AM -0400, Kuba Ober wrote:
I have questions to the kind folks at Jane Street,
and others who use OCaml for commercial/non-research
development: what do you guys use for your development
environment?
vim in an x
> What are killer features you dream of?
Clearly, the ability to click on a function to go to the place where it is
defined is the only reason why I switched from emacs to Eclipse ... And I
would be very happy to switch to a faster IDE because Eclipse is so slow on
big project.
Thomas
___
On Mon, Oct 20, 2008 at 09:19:40AM -0400, Kuba Ober wrote:
> I have questions to the kind folks at Jane Street,
> and others who use OCaml for commercial/non-research
> development: what do you guys use for your development
> environment?
vim in an xterm for me :)
> What are killer features you d
I have questions to the kind folks at Jane Street,
and others who use OCaml for commercial/non-research
development: what do you guys use for your development
environment? What would be the minimal set of functionality
that would make you happy for an IDE? What are killer features
you dream of?
I'
76 matches
Mail list logo
