<d_bot>
<rbjorklin> Do you have any kind of budget for this stuff? I used to work for https://www.apptus.com/ and their ecommerce platform is pretty solid. In-memory database with search, navigation, recommendations the whole shebang.
waleee has quit [Ping timeout: 240 seconds]
mbuf has joined #ocaml
<d_bot>
<rbjorklin> The landing page is full of fluff nowadays but if you want to look into it in a bit more detail their docs page is pretty good: https://docs.apptus.com/
hackinghorn has joined #ocaml
wyrd has quit [Ping timeout: 276 seconds]
hackinghorn has quit [Client Quit]
hackhorn has joined #ocaml
hackhorn is now known as hackinghorn
hackinghorn has quit [Remote host closed the connection]
troydm has quit [Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset]
troydm has joined #ocaml
hornhack has joined #ocaml
hornhack has quit [Remote host closed the connection]
<d_bot>
<let Butanium = raise Not_found;;> I'm looking at the optimization page of the ocaml website :
<d_bot>
<let Butanium = raise Not_found;;> > Owl: a scientific computing library that accelerates mathematical code. If you’re considering writing code that’s heavy in floating point math, you should be using Owl.
<d_bot>
<let Butanium = raise Not_found;;> What's a code heavy in floating point math ?
<d_bot>
<Alistair> data science stuff I imagine
xiongxin has joined #ocaml
<d_bot>
<bnguyenv> I'd say there are two topics. As the page says, one of the difficulties is that floats are boxed. With enough flambda inlining and unboxing that can be ok though. The other is if you're doing linear algebra (or just vectorized operations on arrays), then you want BLAS etc, and Owl can give you a convenient interface (a la numpy) (but I've never used it).
<d_bot>
<bnguyenv> In that case I think owl-base is enough.
<d_bot>
<bnguyenv> Personally I've used lacaml and odepack for simple linear algebra and ODE integration (because at the time Owl was just starting and was a bit too big for me).
pieguy12- has quit [Ping timeout: 260 seconds]
mro has quit [Read error: Connection reset by peer]
mro_ has joined #ocaml
<d_bot>
<VPhantom> The problem is that our complexity isn't where most retailers' are. We make some products in-house, outsource some others, we customize in all cases (embroidery, laser engraving, silk screening, etc.) which leads to a fairly complex catalogue. Products have variants and those have options, customers have corporate-set budgets, etc.
spip has joined #ocaml
bobo_ has quit [Ping timeout: 256 seconds]
<d_bot>
<VPhantom> We looked at platforms like Shopify Plus (used by Staples) and it's too cookie-cutter for us.
perrierjouet has quit [Quit: WeeChat 3.4]
jlrnick has joined #ocaml
hackinghorn has joined #ocaml
mro_ has quit [Remote host closed the connection]
biog has joined #ocaml
perrierjouet has joined #ocaml
xiongxin has quit [Ping timeout: 240 seconds]
xiongxin has joined #ocaml
unyu has quit [Quit: Reboot.]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
xiongxin1 has joined #ocaml
xiongxin has quit [Ping timeout: 256 seconds]
xiongxin1 is now known as xiongxin
mro has joined #ocaml
Everything has joined #ocaml
unyu has joined #ocaml
xiongxin has quit [Ping timeout: 256 seconds]
xiongxin has joined #ocaml
<d_bot>
<cemerick> there's a lot more to e.g. liveview than just server-side rendering, but yeah
<d_bot>
<cemerick> eliom is a different thing altogether; the multitier concept is appealing, but not looking to buy into something like that at this point
Haudegen has quit [Quit: Bin weg.]
waleee has joined #ocaml
waleee has quit [Ping timeout: 240 seconds]
waleee has joined #ocaml
<d_bot>
<VPhantom> About Hotwire & co, isn't this basically going back to good old "AJAX"? Like <https://htmx.org/> and such modern takes.
<d_bot>
<mseri> Note that owl-base does not use blas/lapack, it is all ocaml
<d_bot>
<mseri> To use optimized libraries you need to use `owl`
<d_bot>
<mseri> Or, as suggested lacaml
<d_bot>
<mseri> Sorry, I was still logged with the wrong account
<d_bot>
<bnguyenv> Oh ok thanks for the correction !
<d_bot>
<mseri> Np. It is useful if you want to use it to compile for the browser for interactive simulations for example
<d_bot>
<Bluddy> Has the merge of the multicore PR been celebrated here yet?
<d_bot>
<Bluddy> Found it
waleee has joined #ocaml
mro has joined #ocaml
waleee has quit [Ping timeout: 252 seconds]
mro has quit [Ping timeout: 240 seconds]
xiongxin has quit [Quit: xiongxin]
unyu has quit [Quit: brb]
gravicappa has joined #ocaml
jlrnick has quit [Ping timeout: 256 seconds]
pieguy128 has joined #ocaml
unyu has joined #ocaml
pieguy128 has quit [Ping timeout: 256 seconds]
kakadu has quit [Quit: Konversation terminated!]
pieguy128 has joined #ocaml
pieguy128 has quit [Ping timeout: 256 seconds]
Haudegen has quit [Quit: Bin weg.]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
xd1le has quit [Quit: xd1le]
mro has joined #ocaml
bartholin has quit [Quit: Leaving]
mro has quit [Ping timeout: 240 seconds]
Haudegen has joined #ocaml
dalek-caan has joined #ocaml
mro has joined #ocaml
mro has quit [Quit: Leaving...]
mbuf has quit [Quit: Leaving]
<d_bot>
<mseri> @Bluddy it started here 🙂
<d_bot>
<Kakadu> What is the best way to explain a newbie, that putting a mutable field 'value' to part of AST that represents variables, is a bad idea?
<Corbin>
It sounds like some sort of basic constant propagation? It might be fine if wrapped with a `result`.
<d_bot>
<Kakadu> No, he's going to write an interpeter with assignment, and needs to store values of various variables.
<d_bot>
<Et7f3> use a exemple with shadowing ?
<d_bot>
<Kakadu> @Et7f3 Could you expand your idea with more details?
<d_bot>
<Et7f3> `let foo = 3 in 4 + 4` is stored with something like that `Bind{name="foo", value=Int{value=3}, exp=Plus{lhs=Int{value=4}, Int{value=4}}, value=0}`?
<d_bot>
<Et7f3> then I will just show a exemple with many Bind and he will see how it is slow to access variable and will present map.
<d_bot>
<Kakadu> I don't know yet.... Right now I got an idea, that if variabless occurs in code many times, how will assignment of one will be propagated to other occurences....
dalek-caan has quit [Quit: dalek-caan]
<d_bot>
<Et7f3> One advice I can give is at least to use adt instead of bool+ref so he doesn't forget to check it
<d_bot>
<Et7f3> The only reason that can break is if you want a step back feature in the interpreter
<d_bot>
<Et7f3> value is in variable_t is in record_content is in record_t is in object_t so it basically mean that when in the language we write: `someObject.field = 3` it mutate in memory object
gwizon has quit [Ping timeout: 256 seconds]
waleee has joined #ocaml
pieguy128 has joined #ocaml
pieguy128 has quit [Ping timeout: 240 seconds]
<d_bot>
<KW78> Isn't the the AST somehow separate from the environnement which hold the variables. ASTs are typically immutable (unless you are doing in place AST to AST transformation, but I would guess it is not that here). The environment contains the "foo" variable. When evaluating / interpreting, a Bind node will update the environment. (Env.add "foo" 8 myenv).
<d_bot>
<KW78> this solves the problem of "propagating"
<companion_cube>
in OCaml, the typedtree is mutable, afaik
<companion_cube>
beause it does contain the bindings
<d_bot>
<KW78> but not that of shadowing / scope.
pieguy128 has joined #ocaml
<d_bot>
<KW78> but why would the bindings change ? unless you want some AST transformation
gravicappa has quit [Ping timeout: 240 seconds]
<d_bot>
<octachron> The typedtree is immutable, it is type expressions that are mutable in order to handle variable unification with an union-find.
<d_bot>
<KW78> ok that makes sense
<companion_cube>
if you want to be pedantic and separate types from typedtree :p
<d_bot>
<Kakadu> @KW78 I understand how having an environment helps with propagation. I want a concrete points why proposed "ast" is bad
<d_bot>
<KW78> I think one reason is prececily how to you map all occurences of an variable in a AST.
<Corbin>
Concretely, ASTs should be immutable; syntax is immutable, and that should include abstract syntax.
<Corbin>
Earlier, when you first asked, I wanted to suggest teaching about Harvard-style machines where code is always immutable. But I'm still not sure whether that would be an appropriate topic for newbies.
<companion_cube>
OCaml has mutable types for good reasons, though :)
mro has joined #ocaml
<Corbin>
Sure. But remember Pirsig's definition; "good" is what you like. (Also remember that Pirsig emphasized not demeaning "good" simply because it's an opinion!)
<d_bot>
<Kakadu> @companion_cube Is it the case where mutability required?
<companion_cube>
I mean it's not required, as far as I can tell. It's just faster.
<d_bot>
<Kakadu> @companion_cube Faster to produce spagetti or faster for perfoance reasons?
<d_bot>
<Kakadu> perfomance*
<companion_cube>
performance is better
<companion_cube>
the typechecker spends a lot of time dereferencing metavariables
<d_bot>
<Kakadu> Yeah, in context of OCaml's type inference you are right, but I'm more interested in mini-Kotlin example above
<d_bot>
<Kakadu> @Corbin we explain newbies about Harvard architecture but I don't understand how it is relevant to my original question
<companion_cube>
I haven't followed, but how do you do when there's multiple instances of a variable?
<companion_cube>
like in a recursive call
<d_bot>
<Bluddy> Immutable trees are good when they're simple. The more abstract interpretation/types you add to them, the less simple they become, and the more you might as well use mutability.
<Corbin>
Kakadu: If they can understand that it's acceptable for a computer to have immutable code, then hopefully it's not hard to explain to them that an AST is a code object, and thus that it can be reasonable for ASTs to be immutable.
<companion_cube>
are AST "code object"? hmmm :p
<d_bot>
<Bluddy> At a certain point, to stay immutable, you're handling multiple maps from id to value, where the id represents a node. So now you need to handle garbage collection on that map. Might as well just use references.
<d_bot>
<Bluddy> @Kakadu the newbie doesn't understand that the AST is completely separate from the state machine that interprets the AST. The state machine is far easier to make mutable. The AST is much cleaner when it's immutable.
<d_bot>
<Kakadu> > ... you're handling multiple maps from id to value, where the id represents a node. So now you need to handle garbage collection on that map. Might as well just use references
<d_bot>
<Kakadu> Does it implies that we need to prepare beforehand places in AST for new information, which implies high coupling?
<Corbin>
companion_cube: A practical example: My preferred JIT toolkit can accelerate AST-walking interpreters, but only really works when the AST is immutable.
<companion_cube>
ah, JITs, such a good example of code always being immutable :)
<companion_cube>
(I imagine you talk about graal?)
<Corbin>
(RPython, actually. Fun fact: I changed Monte's RPython codebase to *remove* a bytecode compiler, and it got faster; the bytecode format was cyclopean compared to the AST, I guess.)
<companion_cube>
rpython does sound cool
<companion_cube>
not really related to my point about ocamlc, which itself wasn't really related to the kotlin AST above, though :)
<d_bot>
<Bluddy> I think so. If you're trying to coordinate multiple trees (e.g. an effect tree, a type tree, a syntax tree), pure immutability quickly becomes painful. I did it in haskell and it was awful. But if you keep the tree structure simple, things remain easy to manage.
<d_bot>
<Bluddy> And then immutable trees are by far the best.
<d_bot>
<Bluddy> That's what OCaml does -- it doesn't decorate the tree, but rather transforms it entirely at every step.
<d_bot>
<Bluddy> Although it still uses mutability for efficiency
<d_bot>
<Kakadu> Yes, but it *should* hurt performance!
<d_bot>
<Kakadu> I'm talking about tranforming to entire new tree
<d_bot>
<Bluddy> You're not doing that during evaluation of the interpreter! If it's just a typing stage, and then some other analysis stage etc -- those things are cheap.
<d_bot>
<Bluddy> creating the new tree isn't a dominant cost in that case
<d_bot>
<Bluddy> the interpreter should not work this way at all
<d_bot>
<Kakadu> > creating the new tree isn't a dominant cost in that case
<d_bot>
<Kakadu> Can you recommend papers/projects that measure it?
<d_bot>
<Bluddy> I really don't know. How many times are you going to be transforming the tree?
<d_bot>
<Bluddy> Most times you have an input and you go through several stages to produce the output. Even 50 stages are going to be trivial in most instances.
<d_bot>
<Bluddy> That's kind of what functional programming excels at: immutable input -> immutable output. That's why they're so good for compilers
<d_bot>
<Kakadu> > Even 50 stages are going to be trivial in most instances.
<d_bot>
<Kakadu> If we have an another type for AST for every (nano) pass of optimisation, I suspect that most parts of AST should be just copied, so overall performance is going to be pessimised. It's difficult for amy to imagine any structural sharing between stages.
dstein64- has joined #ocaml
dstein64 has quit [Ping timeout: 256 seconds]
dstein64- is now known as dstein64
<zozozo>
about the "creating a new tree isn't a dominant cost": I have a project that does parsing and typing of SMTLIB problems, and where I can compare to state-of-the-art SMT solvers
<zozozo>
my project in ocaml ofc, first produces a parsetree (immutable), and then a typedtree (where type have a very very little bit of mutability for inference)
<zozozo>
and it is still faster than cvc4 which directly creates a typedtree
<zozozo>
(though a large part ofd the speed difference is likely due to the performance of the parser that menhir generates vs hand-written recursive descent parsers)
<companion_cube>
hmmm doesn't cvc4 use antlr? :p
<zozozo>
companion_cube: maybe, I don't really know, :p
<companion_cube>
(I never asked but did you compare with yices2?)
<zozozo>
not yet, maybe i'll do a more exhaustive round of testing one day
<companion_cube>
cause on this particular language, the handwritten parser might still be much faster :p
<companion_cube>
well try it
<companion_cube>
it's very likely it'll beat cvc4
<zozozo>
ok, I'll try as soon as I can
Everything has quit [Quit: leaving]
<zozozo>
very surprisingly, yices2 doesn't appear to be packaged on archlinux
<zozozo>
ah, I spoke too fast, yices2 isn't a package, but there is a yices package version 2.6
Tuplanolla has joined #ocaml
jlrnick has joined #ocaml
jlrnick has quit [Ping timeout: 252 seconds]
<d_bot>
<Bluddy> Most optimizations can probably work on the same AST type, no? Nano-optimizations usually look for specific patterns and eliminate them, so you don't need a new type for each stage.
<d_bot>
<Bluddy> In any case, I recommend going for the simple solution first and only optimize if you find that it's necessary
<zozozo>
Bluddy : well, in my case the two AST are quite distinct: one is really just a structured representation of the input text, and the other should only represent well-typed terms and formulas
<zozozo>
and it depends on the context, but at least for compilers, you often need a lot of different ASTs (because each step has different requirements on what you want to represent), and having a single AST would introduce a lot of runtime assertions of the kind: this AST case cannot happen at this stage of the pipeline
mro_ has joined #ocaml
mro has quit [Ping timeout: 240 seconds]
cedric has joined #ocaml
biog has quit [Quit: ZZZzzz…]
Serpent7776 has quit [Quit: leaving]
mro_ has quit [Quit: Leaving...]
biog has joined #ocaml
breakwindows has joined #ocaml
rgrinberg has joined #ocaml
cedric has quit [Quit: Konversation terminated!]
breakwindows has quit [Ping timeout: 256 seconds]
biog has quit [Quit: ZZZzzz…]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
biog has joined #ocaml
xenu has quit [Quit: leaving]
xenu has joined #ocaml
spip has quit [Read error: Connection reset by peer]