<flux>
pippijn, quite nice. I find it a bit unfortunate there are dynamically parsed expressions there, though.. unless you intend to read the whole description from a stylesheet file.
Submarine has joined #ocaml
Submarine has quit [Changing host]
Submarine has joined #ocaml
<pippijn>
flux: you can also construct them yourself
<pippijn>
flux: they are not dynamically parsed
<flux>
pippijn, that's great then :)
<pippijn>
flux: they are "statically" parsed
<pippijn>
before the widget is constructed
<flux>
I mean they are parsed at runtime.
<pippijn>
they are parsed before main()
<flux>
therefore most errors won't appear during compile time.
<pippijn>
oh well
<flux>
and the error messages likely won't tell the line number :)
<pippijn>
you can construct them at compile time :)
<pippijn>
it's just more verbose
<pippijn>
also..
<pippijn>
evaluation still happens at runtime
<pippijn>
you can construct invalid constraints
<flux>
but at least you won't refer to invalid identifiers
<pippijn>
oh, you will
<pippijn>
identifiers are never compile time
<pippijn>
maybe they could be.. hmm
<flux>
something like: let ident1 = mk_ident "ident1" - but that's a bit of boilerplate
<pippijn>
ah
<pippijn>
I thought you meant using direct pointers to the widgets instead of strings
<flux>
no, that would be quite difficult to arrange I imagine
<pippijn>
but actually, I intend to make the whole thing QML-like
<pippijn>
the expression parser is part of that
<pippijn>
that way, I will have the QML file for a declarative structure and positioning description. I can do any number of sanity checks on that
<pippijn>
I don't know how to handle the dynamic part of the UI, yet
<pippijn>
the part that involves I/O and data
<pippijn>
at some point, I will need mutable data, unless I go through the entire widget hierarchy every time something is updated
<pippijn>
that's not going to work, because I'm going to have around 8 UI updates per second
<adrien>
thelema: thanks; and had you not run it on some projects you take part in?
<mrvn>
thelema: I gave up on the idea of using a bidirectional map. Got a better solution.
mattrepl has joined #ocaml
<mrvn>
thelema: first I compute a distance map (simple matrix or hashtbl). Then I generate a unidirectional graph containing all possible paths of minimum cost from that. Every time the unit moves it follows an edge in the graph, rembers the new node and forgets the node it came from. The GC will then automatically clean up nodes no longer needed.
<saml>
can i use that for java code ?
<mrvn>
thelema: And the good thing is that the graph can be mostly shared when moving a large group of units (like 100 soldiers marching towards an enemy tower).
<mrvn>
saml: ?
<saml>
ocaml metrics. it says it's ocaml analysis tool
<saml>
not for java
<adrien>
I bet the wikipedia articles on the metrics have links for java
<mrvn>
just theoretically you could interface ocaml with java. But have fun with that.
<mrvn>
hey, anyone made a ocaml -> java bytecode compiler? :)
<saml>
ocaml and java are pretty much the same
<saml>
sed one liner can transform ocaml to java and vice versa
<mrvn>
except that java sucks and ocaml has fun. :)
<Hodapp>
but Java has...
<Hodapp>
uh...
<iZsh>
ocaml and java pretty much the same ? O.o
<mrvn>
saml: if it is that easy then why not translate the ocaml metrics to java? :)
<saml>
so i'm reading about struct and sig
* Hodapp
looks at saml and "sed one liner" etc.
<mrvn>
saml: yes?
<mrvn>
In java terms I guess you could say a struct "implements" a sig.
<pippijn>
q.e.d.
<pippijn>
also, ocaml -> java bytecode shouldn't be too hard, right?
* Hodapp
shrugs
hiptobecubic has joined #ocaml
<pippijn>
can I make ocamlc output its intermediate (lambda) representation?
<adrien>
-dlambda
gnuvince has quit [Ping timeout: 250 seconds]
<pippijn>
ah yeah, there it is
<pippijn>
and can I prevent it from making .cmi and .cmo files?
<adrien>
?
<pippijn>
I can prevent it from making an a.out with -c
<diml>
also according to this you must always watch the socket for read events (even for send)
<hcarty>
diml: Is this possible in Lwt (watching for both read and write events)?
<diml>
hcarty: no (well yes... but it won't be pretty), but according to this the fd must only be watched for read events
<diml>
does it work well with your current code ?
<hcarty>
diml: It hasn't failed yet
<hcarty>
Without the retry loop it had usually failed by now
<diml>
i mean, does it never block ?
cago has quit [Quit: Leaving.]
mika1 has quit [Quit: Leaving.]
<hcarty>
diml: It has not yet
<zaltekk>
ugh. looks like i don't only need soap/wsdl, but also ntlm auth
<hcarty>
It does go into the retry function, but never more than once.
<zaltekk>
but luckily i've still found everything on cpan :P
<hcarty>
diml: I may try changing the send wrapper to use Lwt_unix.Read as well
iago has quit [Quit: Leaving]
ftrvxmtrx has quit [Ping timeout: 245 seconds]
ftrvxmtrx has joined #ocaml
<zaltekk>
bleh. can't get LWP::Authen::Ntlm working with https. anyone got experience with this?
<pippijn>
shouldn't you ask in a perl channel?
<zaltekk>
oh wow, sorry, thought I was typing in that channel :P
Juzor has joined #ocaml
<Juzor>
Hi , I have a problem compiling my project with ocamlc , I try to compile modules but I have a problem like circular dependencies, what is the way to fix it a flag to specify cmi files or forward declaration ?
<adrien>
no forward declarations
<adrien>
typically, move the types to a separate file
<Juzor>
nice move
<Juzor>
hum, the problem is not on types but on modules
<Juzor>
A need B need C but C need B
<Juzor>
thing like that
<pippijn>
impossible
<pippijn>
redesign
<Juzor>
Wut
<adrien>
move the code to a common file then
<adrien>
or
<pippijn>
you can pass B as an argument to C
<adrien>
that ^
<pippijn>
or a function (or functions) from B to C's functions
<adrien>
or members of the B module as arguments
<Juzor>
Warrior style
<pippijn>
that ^ :)
* adrien
repeatedly hits pippijn, grabs adhesive tape and attaches him in a corner
<adrien>
no more stealing what I say! :P
<pippijn>
;)
<adrien>
='(
ocp1 has quit [Ping timeout: 272 seconds]
avsm has quit [Ping timeout: 260 seconds]
<mrvn>
Juzor: if you can't work around the circular depends then you need to move the modules into a single file and declare them a recursive modules.
<Juzor>
mrvn: in a single file with sign struct keywords ?
<mrvn>
Juzor: other than what was already suggested you can have modules B and C and a BC modules that contain the circular parts.
<Juzor>
redundancy types ?
<mrvn>
# module rec M : sig val foo : 'a -> 'a end = struct let foo x = N.bar x end and N : sig val bar : 'a -> 'a end = struct let bar x = M.foo x end;;
<mrvn>
module rec M : sig val foo : 'a -> 'a end
<mrvn>
and N : sig val bar : 'a -> 'a end
<mrvn>
As you can see M.foo calls N.bar and N.bar calls M.foo.
<mrvn>
Using closures to resolve the cycle would be: # module M = struct let foo bar x = bar x end module N = struct let rec bar x = M.foo bar x end;;
<mrvn>
module M : sig val foo : ('a -> 'b) -> 'a -> 'b end
<mrvn>
module N : sig val bar : 'a -> 'b end
<mrvn>
Juzor: Using a common lower module would be: # module C = struct let rec foo x = bar x and bar x = foo x end module M = struct let foo x = C.foo x end module N = struct let bar x = C.bar x end;;
<mrvn>
module C : sig val foo : 'a -> 'b val bar : 'a -> 'b end
<mrvn>
module M : sig val foo : 'a -> 'b end
<mrvn>
module N : sig val bar : 'a -> 'b end
<mrvn>
the rest is left as an exercise to the reader :)
tmaedaZ is now known as tmaeda
djcoin has quit [Quit: WeeChat 0.3.2]
lorill has joined #ocaml
<lorill>
join #ocaml-fr
<Juzor>
okay pb fix ty
<hcarty>
diml: I've been away for a bit, but I did get a block eventually.
lorill has quit [Quit: Quitte]
avsm has joined #ocaml
tmaeda is now known as tmaedaZ
tmaedaZ is now known as tmaeda
avsm has quit [Quit: Leaving.]
oriba has quit [Quit: oriba]
roha has joined #ocaml
gnuvince has quit [Ping timeout: 244 seconds]
gnuvince has joined #ocaml
<diml>
hcarty: the fd returned by ZMQ is a socketpair which i think is just used for notifications, that's why it must be monitored for read
<IbnFirnas>
adrien: re: GODI package name conflicts - I gave-up and installed an older GODI release (2011-07) - so far so good! (sorry I'm days late with this...)
avsm has joined #ocaml
fraggle_ has joined #ocaml
Juzor has quit [Remote host closed the connection]
sivoais has quit [Quit: Lost terminal]
smerz has joined #ocaml
Submarine has joined #ocaml
Submarine has quit [Changing host]
Submarine has joined #ocaml
Submarine has quit [Remote host closed the connection]
hiptobecubic has quit [Ping timeout: 245 seconds]
ftrvxmtrx has quit [Ping timeout: 240 seconds]
pangoafk is now known as pango
thelema has quit [Remote host closed the connection]
Zedrikov has joined #ocaml
thelema has joined #ocaml
<rwmjones>
does anyone know if native dynlink is supported in ocaml > 3.12.1 on *ARM*?
<rwmjones>
3.12.1 says
<rwmjones>
native dynlink ........... false
<rwmjones>
I don't have a later version handy ..
<rwmjones>
ah well, turns out it's been fixed upstream
<pippijn>
the problem is that it will try to minimise a function and in my case, the minimisation function is actually negative
<flux>
pippijn, can't you add a constrant like 1/(x*y) or some such to make it prefer large areas?
<pippijn>
I could invert all properties
<flux>
(or optimizatino target)
<thelema>
minimize the opposite?
<pippijn>
flux: my optimisation target is -(sum areas)
<pippijn>
and that's fine, it works
<flux>
1d optimization target sounds a bit simplistic?-o
<pippijn>
the problem is that it will start by trying small x/y and w/h
<flux>
well, maybe it'll do
<pippijn>
flux: why?
<flux>
no reason, just sounds like this problem wouldn't be so simple :)
<pippijn>
my target is maximum use of screen space
<flux>
it shouldn't matter what it starts with, it should end up with the same result, if the cost function is correct and doesn't have annoying behavior
<flux>
or is your problem that it doesn't converge fast enough?
<pippijn>
it converges fast enough at the moment
<flux>
I would imagine you can somehow suggest it to start with bigger values
<pippijn>
0.01 seconds for the 4 frames in my example
<flux>
is that an acuurate value? one second for 400 frames?
<pippijn>
definitely not
<pippijn>
it depends on the degrees of freedom
<pippijn>
if you have 0 degrees of freedom (1 solution), it's just a matter of solving a single system of linear equations
<pippijn>
so it will be fast
<pippijn>
but consider a lot of frames and each of them has complete freedom
<pippijn>
the result will be that every frame takes up the complete screen
<pippijn>
overlapping
<flux>
hmm, but the frames won't vary? or this is the problem that you would like to have mutability to cache values?
<pippijn>
but before it gets there, it has to try every solution
<pippijn>
from 0x0 0x1 1x0 1x1 ... 80x25
<adrien>
thelema: ah, ok; I've never found ocaml's commit messages to be very explicit
<pippijn>
I would like it to start at the upper bound of the value domain
<pippijn>
now it starts at the lower bound
Submarine has quit [Remote host closed the connection]
<pippijn>
if it starts at the upper bound, it's likely to find the optimal solution right away or within very few steps
<pippijn>
right now I always have the worst case
<flux>
well, if facile cannot be told where to start at, yuo can achieve the same with some mapping of values I suppose
<pippijn>
yeah..
<pippijn>
1 frame with 10 frames in it
<pippijn>
each with complete freedom
<pippijn>
found maximal solution after #3882 attempts
<pippijn>
solved in 1.632826 seconds
<flux>
heh
<pippijn>
complete freedom is not a likely use case
<pippijn>
but it would be 0.01 seconds if it started at the upper bound
<thelema>
pippijn: so modify the solver to start where you want
<pippijn>
thelema: your solution to everything is to fork the library, isn't it?
<thelema>
:)
<thelema>
if the code doesn't do what you want.
<thelema>
I don't know the library, maybe it's got provision for this already?
<thelema>
oh, this is a bigger library than I expected.
<thelema>
you want a inverted Goals.indomain, right?
<pippijn>
yes, I think so
<thelema>
Use Goals.instantiate
<thelema>
Module Goals also provides the function Goals.instantiate that allows to specify the ordering strategy of the labeling.
<thelema>
Goals.instantiate takes as first argument a function to which is given the current domain of the variable (as single argument) and should return an integer candidate for instantiation.
<pippijn>
found maximal solution after #540 attempts
<pippijn>
solved in 0.209899 seconds
<pippijn>
much better
<pippijn>
I think this is optimal
<pippijn>
excellent, now the regular use cases are all close to 1 attempt :)
<pippijn>
thelema: thanks
<thelema>
pippijn: next time, maybe read the docs?
<pippijn>
yes
Snark has quit [Quit: Quitte]
<pippijn>
"Labeling of variable x in decreasing order is then merely"
<pippijn>
thelema: right.. the docs
ulfdoz has joined #ocaml
roha has quit [Ping timeout: 248 seconds]
_andre_ has quit [Quit: leaving]
<pippijn>
is it recommended to open BatPervasives everywhere?
<thelema>
pippijn: it's recommended to open Batteries
<thelema>
which will implicitly open BatPervasives
<pippijn>
ah
<thelema>
opening batteries will also make all BatFoo available as Foo, with BatList and the rest of the stdlib extensions integrated into the stdlib modules
ulfdoz has quit [Ping timeout: 252 seconds]
<pippijn>
ok, that doesn't work, but Batteries_uni works
<thelema>
grr, 1.x... when compiling with threads, "open Batteries" works, when compiling without, "open Batteries_uni"
<pippijn>
ok
<smondet>
thelema: BTW, is it planned to have a Batteries.LabelsExceptionless ? (something that replaces List by the exceptionless, labels versions?)
Zedrikov has quit [Quit: Bye all, see you next time!]
<thelema>
smondet: yes, although it's low on my todo list, so it will likely require someone else to implement
<thelema>
smondet: if you're able, it should be straightforward to add all the required submodules to Batteries.
larhat has joined #ocaml
<thelema>
modify the batteries.ml file to make this new module
hto has quit [Quit: leaving]
hto has joined #ocaml
saml has quit [Quit: Leaving]
testcocoon has quit [Quit: Coyote finally caught me]
tufisi has quit [Ping timeout: 260 seconds]
testcocoon has joined #ocaml
pr0zac is now known as Koodhzdie
Koodhzdie is now known as Koodhzie
Koodhzie is now known as AFIP
AFIP is now known as Pr0zac
gp has joined #ocaml
larhat has quit [Ping timeout: 260 seconds]
gp has quit [Client Quit]
oriba has joined #ocaml
ftrvxmtrx has joined #ocaml
Cyanure has quit [Remote host closed the connection]
The_third_man has quit [Ping timeout: 246 seconds]