<mrvn>
let wire = new Gate.Gate.wire in segfaults.
<mrvn>
The really strange part is that everything worked before I moved stuff from main.ml to Gate/
<flux>
cool, a segfaulting ocaml program
<mrvn>
And it isn't even the part that uses Obj.magic
<flux>
..
<flux>
so it crashes without the ui as well?
<mrvn>
can't really test that. But it crashes in the constructor for wire and that calls nothing from the gui.
<mrvn>
If I move Gate/*.ml to . then it works again.
<flux>
I simplified it a lot and it still crashes
<adrien>
maybe it has something evaluated when you start the program and calling the constructor triggers the GC (or something along that)
<flux>
main.ml indeed simplifies to: let _ = new Gate.Gate.wire
<flux>
I think I know what the problem may be..
<flux>
you have two modules called Gate?
<flux>
no
<flux>
nvm, Gate.ml doesn't get built :)
<mrvn>
Not really. But lets test if module and pack name must differ
<mrvn>
flux: damn, that is it.
<flux>
I think that might actually be a bug..
<flux>
ocaml should usually be quite strict what it accepts
<flux>
although it may also be a bug in your build
<mrvn>
flux: make clean && make
<mrvn>
I don't think anything is build wrong.
<flux>
I meant in how the build is made
<flux>
but no, it seems reasonable
<flux>
the problem might be that a pack cannot be called the same as a module it contains
<mrvn>
Lets test that
<flux>
how about supporting ocamlc as well..
<mrvn>
must I? :)
<flux>
pretty program. but how come you're using the Graphics-module for that?
<mrvn>
What else should I use?
<flux>
well atleast TCL, GTK or even SDL maybe?-)
<flux>
s/TCL/TK/
<mrvn>
sdl maybe. gtk takes way to much to just draw something
<adrien>
sdl has that big problem you can't draw lines though, but opengl should work
<mrvn>
huh? Sure you can draw lines
<flux>
sdl has some auxiliary lib for drawing lines etc
<flux>
but I don't think ocaml has bindings to it
<flux>
then there is sfml, which also has ocaml bindings
<flux>
sfml is accelerated as well
<adrien>
horizontal or vertical lines, but good luck drawing something else (well, it's doable but you better not reinvent the wheel if you want something of an ok quality) and there are indeed external libs, but no binding that I know
<flux>
it appears there's no bug for that (not atleast with keywords segmentation pack)
<mrvn>
flux: I wish the Graphics.X11 module where a little more complete. I would like to open subwindows.
<mrvn>
Having a notion of left, middle and right mouse button might be nice too
<flux>
mrvn, would adding more mouse buttons break existing code?
<flux>
mrvn, also you'll never going to have flicker free stuff using it..
albacker has joined #ocaml
<mrvn>
button : bool; (*true if a mouse button is pressed*)
<flux>
yeah, could simply add 'which button' or buttons
<flux>
(while hoping nobody constructs status records)
<mrvn>
flux: The graphics module does double buffering. You can draw in the background and blit it.
<flux>
oh
<mrvn>
flux: That would be source compatible, if nobody creates status records.
<mrvn>
In GraphicsX11 I would just create a completly new status structure. So far the only thing GraphicsX11 can do is get the window_id, create a subwindow and close one. Only usefull thing you can do is start other apps with --root=<id>, if they support that.
<mrvn>
Would be ncie if one could actually draw into the subwindows.
<flux>
maybe batteries could have an enhanced Graphics-module :)
animist has quit [Ping timeout: 245 seconds]
<mrvn>
sdlvideo.mli can indeed only put pixels and rectangles. No lines.
animist has joined #ocaml
<mrvn>
I think I will skip changing to SDL for now. Too much work to add the bindings for 2D primitives.
<mrvn>
Next on my ToDo: Add a Menu at the top.
ygrek_ has joined #ocaml
ygrek has quit [Ping timeout: 245 seconds]
spearalot has quit [Quit: Computer has gone to sleep]
<flux>
so at which point will it still end up being simpler than with (say) lablgtk?-)
presprolo2011 is now known as eelte
<mrvn>
Tons.
Associat0r has joined #ocaml
spearalot has joined #ocaml
schmx has quit [Ping timeout: 265 seconds]
schmx has joined #ocaml
schmx has quit [Changing host]
schmx has joined #ocaml
animist has quit [Ping timeout: 248 seconds]
animist has joined #ocaml
rwmjones has quit [Ping timeout: 245 seconds]
rwmjones has joined #ocaml
ikaros has joined #ocaml
marchdown has quit [Quit: marchdown]
Associat0r has quit [Quit: Associat0r]
<kmkaplan>
In the toplevel system, how do you proceed to reload a .cmo when the signatures have changed? Doing a #load "foo.cmo";; tells me that "The files foo.cmo and foo.cmo disagree over interface Foo"
<thelema>
support more sophisticated module operations in the future, e.g. query and
<thelema>
smart load etc.
<thelema>
I'm looking forward to "smart load" although it seems only planned, and not in progress
<bluestorm>
well, if you want something, you should ping the author
<bluestorm>
the problem with enhtop is that you have to patch and recompile ocaml
<bluestorm>
it makes it really difficult to distribute (and possibly heavy to maintain), so you shouldn't count on other people using it
<thelema>
yes, I'm thinking this could be doable through findlib-style extensions to the toplevel
Smerdyakov has joined #ocaml
boscop_ has joined #ocaml
boscop has quit [Ping timeout: 245 seconds]
ntaylor has joined #ocaml
ulfdoz has joined #ocaml
<Smerdyakov>
Has anyone here wished for some web application but decided it would be too much work to implement/host?
<schmx>
Yes.
Yoric has quit [Quit: Yoric]
<Smerdyakov>
schmx, can you share any more details? I am trying to help people in that situation realize their dreams. :)
<bluestorm>
Smerdyakov: I'm currently wishing for an opensource forum software that I could easily ruse, extend and maintain
<schmx>
Smerdyakov: I don't quite remember the app at this time, but it seemed I would have to learn css and html and webprogramming and what heck.
<Smerdyakov>
bluestorm, if I built something like that, would you be interested in testing it?
<schmx>
Smerdyakov: and javascript and "webtechnology"
<bluestorm>
hm
* sdschulze
thinks that web applications -- at least in the way Google envisions them -- are totally overrated.
<Smerdyakov>
schmx, well, you don't need to learn much of that with Ur/Web, and I'm trying to develop libraries that make it possible to learn even less of it.
<bluestorm>
Smerdyakov: I want to software stack to be open-source
ikaros has joined #ocaml
<Smerdyakov>
bluestorm, that fits my plans, too. Only the deployment infrastructure is closed source (for now).
<Smerdyakov>
bluestorm, you can deploy it (hypothetical package) yourself on your own machine, or you can use my stuff to do it cloud-style.
<Smerdyakov>
bluestorm, I'm very interested in identifying domains with a lot of opportunity for customization.
<Smerdyakov>
bluestorm, since I think Ur/Web serves those domains better than anything else, by a wide margin, based on the superior abstraction capabilities.
<bluestorm>
I'm currently considering toying with Ocsigen
<bluestorm>
anyway, I wouldn't want to disappoint you, but I'm not considering actually having users and such for now
<Smerdyakov>
Ocsigen is pretty low-tech, compared to Ur/Web.
<Smerdyakov>
Well, users would be nice, but you would be a user just by trying this out, and then others could use the same software.
<bluestorm>
I'm not convinced that web programming requires really sophisticated technology; it's mostly a lot of very boring things (protocols to support and user interface to polish)
<bluestorm>
well, I could try it, yes
<bluestorm>
I probably would
<Smerdyakov>
It's not a matter of what's required. It's a matter of how to minimize costs of building good stuff.
<bluestorm>
building good stuff is good, reusing passable stuff is even better
<bluestorm>
(hm, seems "passable" is no correct english; think "not that good, but not too bad")
<Smerdyakov>
I knew what you meant. It might even be a common slang word.
<Smerdyakov>
sdschulze, can you elaborate on your view of web applications?
<bluestorm>
sdschulze: sometimes the whole idea of "pushing desktop-like applications inside the web browser" seems inefficient : why not use desktop applications instead ?
<derdon>
uhm, I have a simple yet good proposal for you, thelema
<derdon>
thelema: why don'T you move the html files in doc/batteries/html to the wiki of the github repo?
<derdon>
*don't, dammit
<thelema>
can the wiki just take the HTML files like that?
<derdon>
thelema: maybe you'll find a nice converter which solves this tasks for you ;)
<derdon>
google for html2<the_markup_used>
<thelema>
textile...
<derdon>
ah, I see
<derdon>
I started to write a creole parser for OCaml a few days ago :)
<derdon>
will take some time I guess
<derdon>
thelema: who wrote these html pages?
<thelema>
derdon: it looks like a lot of work. I assume you want editable documentation
<thelema>
the documentation is auto-generated by ocamldoc, from comments in the source
<derdon>
thelema: I want *readable* information. Of course, I could download the source and open it in a web browser
<sdschulze>
Smerdyakov: As soon as you're trying to implement a word processor in JavaScript, something is kinda wrong.
<sdschulze>
OK, the short version: (1) Your data is stored on the network, not on your disk. You must trust the provider in terms of privacy and reliability. (2) Using a web service is effectively like using non-free software. Even if the code is free software, you still can't change the version running on the server. (3) You can't use them without an Internet connection. (4) They are inefficient as hell.
poweredByOcaml has left #ocaml []
waterChip has joined #ocaml
<sdschulze>
Unfortunately, some of these disadvantages to the user are exactly what people who want to make money like about it.
oriba has joined #ocaml
Associat0r has joined #ocaml
Smerdyakov has quit [Quit: Leaving]
<derdon>
thelema: yes, thanks
<derdon>
thelema: was having dinner, sorry for the late response
Associat0r has quit [Quit: Associat0r]
void__ has joined #ocaml
eelte has quit [Excess Flood]
eelte has joined #ocaml
waterChip has quit [Quit: waterChip]
waterChip has joined #ocaml
oc13 has joined #ocaml
<mrvn>
Was there any solution to sorting modules? I need the same for linking.
<adrien>
I don't remember well but doesn't ld-ocaml do something like that?
<mrvn>
You have searched for paths that end with ld-ocaml in suite sid, all sections, and all architectures.
<mrvn>
Not the right thing for this. I have SOURCES = foo.ml bar.ml baz.ml. OBJS = $(patsubst %.ml,%.cmx,$(SOURCES)) [foo.cmx bar.cmx baz.cmx] and then ocamlopt -o prog $(OBJS)
<mrvn>
For that to work SOURCES must be sorted right.
<thelema>
methinks ocamldep needs to have a flag that'll make it output a dep-sorted list
<mrvn>
Best idea I have is to use the .depends file from ocamldep, add a rule %.cmx:\n\t echo $*.ml and then run make to print them in the right order.
<adrien>
we really need to get rid of that +R flag on the channel
<mrvn>
thelema: Then you would have to turn that into a dependency for MAKE yourself.
<thelema>
one detail is that this ordering isn't unique (there's likely many valid orderings), but it shouldn't matter for most programs
<adrien>
> void__ : What's the best OCaml book available? Or do you recommend reading multiple, if so, which? I don't really have to say anything back.
<adrien>
(and to have a channel FAQ)
<thelema>
mrvn: ocamldep does a good job at creating dependencies for make. I want it to just list *all* dependencies in an order such that loading things in that order will satisfy dependencies
<mrvn>
thelema: doesn't matter. only need to be topologically sorted. Having it always the same order for the same input would be good but not even neccessary.
<mrvn>
thelema: me too.
<mrvn>
thelema: But expressing that as dependency for the final program would be most usefull I think.
<thelema>
adrien: agreed fully on +R - it's a pain for me when my connection drops and I end up as thelema_ in the channel, and have to log out and back in
<mrvn>
thelema: You don't you can identify as thelema even when you are thelema_
<thelema>
mrvn: why do you want it in make format? The uses I plan involve just loading a whole bunch of modules to satisfy dependencies automatically
<mrvn>
thelema: Because my use is to use it in the Makefile to link
<thelema>
mrvn: really? I thought I had to /nick myself w/o _ before I could identify
<thelema>
mrvn: and ocamldep doesn't already handle that?
<adrien>
thelema: you can identify as your other account actually... /msg nickserv identify thelema yourpass , and then /nick thelema , it's 100% non-obvious and 99% unknown, I'm under the impression only freenode staffer know about that
<thelema>
I thought it did...
<mrvn>
thelema: no. I thought so too. But aparently you can specify the nick you want to identify for too
<thelema>
adrien: news to me. thank you
<thelema>
I assume that gets around the 'cannot change nick' problem when unregistered in +R channels?
<mrvn>
And the only use for that extended identify is so you can identify before chanigng nicks when chaning nicks requires identifying.
<thelema>
ok, I guess it does
<mrvn>
Can someone explain to me the point of "-native" for ocamldep?
ccasin has quit [Ping timeout: 276 seconds]
<adrien>
thelema: you're welcome, I wish I didn't have to tell you that: I found out when asking ##ircd-seven (or something like that) to allow nick changes to already-registered nicks (not sure how that would have worked with their current codebase though)
<thelema>
mrvn: it seems to explain pretty well in the manual
<thelema>
mrvn: the default dependencies are suboptimal for native compilation as they involve .cmo construction
<mrvn>
thelema: I saw the description but I don't quite see the effect. maybe because I have no .mli file at all.
<thelema>
mrvn: it's exactly for when you have no .mli
<thelema>
at least according to the docs, .cmi dependencies are created on .cmo when there's no .mli
<mrvn>
But then all you need is the .cmx files and they always depend on .cmx files. The .cmo files aren't used at all.
<thelema>
which is what ocamldep does if you give -native
<mrvn>
And no lines for .cmi files.
<mrvn>
I'm right. You need at least one .mli file for it to matter:
<mrvn>
main.cmi: Gui.cmo Gate.cmo
<mrvn>
main.cmi: Gui.cmx Gate.cmx
<mrvn>
Hmm, that doesn't explain why it adds: main.cmo: Gui.cmx Gate.cmx main.cmi. The main.cmo should preferably never be build in native mode, right?
<thelema>
yes, but if you're building native only, it's not going to hurt anything
<mrvn>
Would be nice if you could tell make (Gui.cmo Gate.cmo) | (Gui.cmx Gate.cmx). Pick the one you need to build anyway.
waterChip has left #ocaml []
<thelema>
mrvn: too fluffly
oriba has quit [Quit: Verlassend]
void__ has quit [Quit: Page closed]
mjonsson has joined #ocaml
eelte is now known as coucou747
Associat0r has joined #ocaml
Associat0r has quit [Client Quit]
oc13 has quit [Ping timeout: 240 seconds]
<mrvn>
thelema: Here is something really flully. Little Makefile that automatically builds and links my source in the right topological order. http://paste.debian.net/74554/
<ygrek_>
who wants to use make when there is ocamlbuild
<mrvn>
ygrek_: How do I use subdirs with ocamlbuild?
bluestorm has quit [Remote host closed the connection]
<ygrek_>
add them to search path with include tag
<mrvn>
With the subdir being part of the module name. Foo/bar.ml -> Foo.Bar.xxx
<ygrek_>
pack?
<mrvn>
Yes. That is what I do. But how do I get ocamlbuild to do that?
<ygrek_>
never used pack, but do you envision any problems?
<mrvn>
Only lack of knowlege or lack of support for it
<mrvn>
I'm just playing around with packs. I think it is a neat idea.
<thelema>
the for_pack(foo) tag in ocamlbuild does packs
<ygrek_>
for-pack iirc
<thelema>
I don't like packs, and have gone with a prefix on module names
<mrvn>
The way I have it know I just set PROGS, LIBS and SUBDIRS and everything else is totaly automatic.
<mrvn>
s/PROGS/PROG/
* ygrek_
thinks that both ways suck and waits for "better module/namespace system for OCaml" (c) acknowledged issue on mantis :)
<mrvn>
I'm only missing one thing now. I want some functions only visible inside the pack.
<mrvn>
ygrek_: so true.
<ygrek_>
hrm, actually that goes for the code too..
<mrvn>
ygrek_: well, makefiles are code too
<thelema>
mrvn: have you reinvented ocamlmakefile?
bluestorm has joined #ocaml
<mrvn>
thelema: like so many others.
Yoric has joined #ocaml
jeddhaberstro has joined #ocaml
<mrvn>
In an *.mli can I say that a submodule has all the things the .ml file declares for it without repeating it all?
Yoric has quit [Quit: Yoric]
ygrek_ has quit [Remote host closed the connection]
<thelema>
mrvn: nope.
<mrvn>
The method set_signal has type Signal.signal -> unit
<mrvn>
but is expected to have type Signal.signal -> unit
<mrvn>
Type Signal.signal = Signal.I.signal is not compatible with type
<mrvn>
Signal.signal = Signal.I.signal
<mrvn>
Don't you love those errors?
<thelema>
yup.
bluestorm has quit [Ping timeout: 264 seconds]
<mrvn>
base.ml declares 'module type Extern = sig ... end'. Pack.mli declares 'module Base : sig include Base.Extern end' with the above error. If I cut&paste the Base.Extern signature 1:1 then it compiles. Any idea?
<sdschulze>
mrvn: in the interactive environment or when compiling?
<mrvn>
compiling
<sdschulze>
any mutually-recursive includes maybe?
<mrvn>
Nope. Just the Pack.mli doing include
<mrvn>
module Signal : sig include Signal.Extern end
<mrvn>
module Base : sig include Base.Extern end
<mrvn>
And the pack contains signal.cmx and base.cmx
<sdschulze>
You don't have to include modules. Using their values and types explicitly suffices, too.
<mrvn>
I want to hide some values
<mrvn>
module type Extern = sig val foo : int end module type Intern = sig include Extern val bar : int end module I : Intern = struct let foo = 1 let bar = 2 end include I
<mrvn>
Extern is the type for outside the Pack and Intern for inside the Pack.
<sdschulze>
mrvn: It's hard to tell it from this.
<thelema>
mrvn: paste the Base.intern signature
<sdschulze>
I was suggesting to upload an example that reproduces the error.
<derdon>
thelema: do I have to create a file called "_tags" which contains the content "<*>: pkg_batteries,pkg_threads"?
<derdon>
thelema: and in what way is ocamlbuild related to this process?
<derdon>
thelema: ah, thanks. you updated it :D
somnium has joined #ocaml
<thelema>
yes, you need two files to (easily) use ocamlbuild with batteries (or any findlib package): myocamlbuild (to create tags that turn on batteries) and _tags (to attach those tags to files)
<derdon>
thelema: or no file at all when I use the simple ocamlfind command ;)
<derdon>
thelema: do you know by accident how to deal with OASIS + batteries ?
<thelema>
derdon: oasis is a possible alternative to autoconf for portable compilation of ocaml code (and some more things). If you wanted to Oasis-ize batteries, I wouldn't mind
<thelema>
but other than that I don't know what you mean by dealing with OASIS and batteries
<derdon>
thelema: I don't really know either :D
<derdon>
still reading the documentation of oasis
<thelema>
derdon: as far as I can tell, OASIS is for people who write ocaml libraries to integrate into the distribution of their library.
<mrvn>
That need to write myocamlbuild files is what I think makes ocamlbuild unusable.
<derdon>
thelema: oh. I thought it was a nice replacement for Makefile, for example. aimed to install projects with dependecies easily
<derdon>
entering "ocaml_batteries foo.ml" compiles foo.ml and creates the executable foo
<thelema>
a (set of) similar shell scripts was distributed with earlier versions of ocaml.
<mrvn>
Anyone ever tried to write a binfmt_misc entry for *.ml files to run them in toplevel?
<thelema>
I rarely make single-file programs
<mrvn>
thelema: there comes the need for ocamldep -l foo.ml again.
schmx has quit [Ping timeout: 260 seconds]
schmx has joined #ocaml
schmx has quit [Changing host]
schmx has joined #ocaml
Amorphous has quit [Ping timeout: 276 seconds]
<ntaylor>
hey all, I'm still new to how OCaml does its partial evaluation, what's the correct way of concatinating strings within a call to printf? Neither printf "hello" ^ "world";; nor printf ("hello" ^ "world");; does the job.
<ntaylor>
(I also found references in mailing lists to the ^^ operator for format strings, but it doesn't work with the version I have, nor did ^ work with the non-format based print_string function.)
<ntaylor>
(I also see references to having to use continuation passing...hopefully the solution isn't that wacky...)
<mrvn>
ntaylor: The first argument to printf is the format and must be a string literal or variable of the right type.
<mrvn>
^ returns a string, not a format for printf.