Re: [Ur] calling javascript code in

[Aistis Raulinaitis]

Adam,

Yes, I've noticed ignored `onload` on tags other than `body`.

It would be good to have a type error or allowing it more broadly.

Aistis

On Mon, Oct 22, 2018 at 11:41 AM Adam Chlipala  wrote:

> Belated follow-up on this remark: now that I look at the types from the
> standard library, I see that 'onload' is statically disallowed for 
> and indeed most other tags.  Is that what you meant?  It could be
> reasonable to add 'onload' more widely, but currently including it for most
> tags should not have 'no effect'.  Instead, it should trigger type error
> messages!
>
> On 7/5/18 2:05 PM, Adam Chlipala wrote:
>
> On 07/05/2018 01:43 PM, Fabrice Leal wrote:
>
> I found out too late for my own good that onload only works for ,
> placing it in a  as no effect
>
>
> Oh, I didn't realize that some event attribute was systematically
> ignored.  That might qualify as a bug!
>
> ___
> Ur mailing list
> Ur@impredicative.com
> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>
___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

Re: [Ur] Error compiling "Anonymous function remains at code generation"

[Aistis Raulinaitis]

After downloading your toy and playing around with it, I realized I was
wrong to assume Regex.match is server side, reading the source it seems to
use the JSFFI..

My guess now is that some of the compiler heuristics changed since that
library was written.
You're probably going to either want to use the new library you wrote or
attempt to resurrect this old one..

On Thu, Sep 20, 2018 at 4:30 PM Fabrice Leal 
wrote:

> @Aistis
> Thanks :)
>
> Check the toy here https://github.com/fabriceleal/urweb-nregex
>
> I tried to coerce my match function to work on the server side my calling
> it via rpc and giving the value back to the page using a 
> I tried 4 ways of coding the predicates to eval chars but to no good
>
>
> https://github.com/fabriceleal/urweb-nregex/commit/57eac6de87fe755ab0a0ce2cf03132c99ef92dd1#diff-28f969b3b5e13b5a7230a77f7d879e2eR95
>
> previous commit compiles, but uses plain list char and "hardcoded"
> function calls instead of char -> bool
>
>
> On Thu, Sep 20, 2018 at 10:53 PM Fabrice Leal 
> wrote:
>
>> @Aistis
>> Just doing your snippet won't typecheck for me;
>>
>> I tried like this
>>
>> ...
>> fun testReR s = return (testRe s)
>>
>> fun index () =
>> r <- rpc (testReR "test 123");
>> return 
>> ...
>>
>> and the error is "Anonymous function remains at code generation" and on
>> top I get "RPC in server-side code"
>>
>> and I tried like this
>> ...
>> fun testReR s = return (testRe s)
>>
>> fun index () =
>> r <- testReR "test 123";
>> return 
>>   
>>
>> and the error is the same "Anonymous function remains at code generation"
>>
>> ==
>>
>> btw, I started another toy project and I seem unable to use curried
>> functions due to them resulting in the same error
>>
>>
>> On Wed, Sep 19, 2018 at 9:05 PM Fabrice Leal 
>> wrote:
>>
>>> ok so this was itching me so I decided to try to isolate whatever is at
>>> fault. and I think I created the simplest sample to reproduce the problem:
>>>
>>> https://github.com/fabriceleal/urweb-test
>>>
>>> so I'm assuming the problem is not at my end and will try to do the
>>> parsing on my own until the urweb-regex lib gets updated
>>>
>>> On Tue, Sep 18, 2018 at 11:01 PM Fabrice Leal 
>>> wrote:
>>>
 I'm having this weird error while trying to compile urweb using
 urweb-regex; if I isolate that page in a separate module, it compiles fine
 (even though I seem unable to access that page from the browser), so I
 assume I'm doing something wrong in my helloworld.ur file.

 Would appreciate some pointers; Source file is this one (
 https://github.com/fabriceleal/urweb-experiments/blob/doesnt_compile/helloworld.ur#L869)
 and I also included the result of -dumpVerboseSource (
 https://github.com/fabriceleal/urweb-experiments/blob/doesnt_compile/dumpVerboseSource.txt#L7705
 )

 That FFI maybe_onload is particularly suspicious ... is the call to
 parsePgn being "lifted" to javascript code? Some time ago I had some errors
 while trying to use the rpc function in the loadPost page because i was
 mixing it with code that uses my canvas library which has a bunch of
 clientOnly FFI calls; I reorganized my code and eventually made it work
 nicely (
 https://github.com/fabriceleal/urweb-experiments/commit/503da7e28f1a05be6e69e9f60c9cd321bfa252ce
 IIRC). I tried to isolate the testParse function but seems to not lead
 anywhere.

 Sorry for the wall of text and thanks in advance :)

 --
 ---
 Fabrice Leal

>>>
>>>
>>> --
>>> ---
>>> Fabrice Leal
>>>
>>
>>
>> --
>> ---
>> Fabrice Leal
>>
>
>
> --
> ---
> Fabrice Leal
> ___
> Ur mailing list
> Ur@impredicative.com
> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>
___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

Re: [Ur] Error compiling "Anonymous function remains at code generation"

[Aistis Raulinaitis]

I'll download your toy and I'll try to get it to work

On Thu, Sep 20, 2018, 14:53 Fabrice Leal  wrote:

> @Aistis
> Just doing your snippet won't typecheck for me;
>
> I tried like this
>
> ...
> fun testReR s = return (testRe s)
>
> fun index () =
> r <- rpc (testReR "test 123");
> return 
> ...
>
> and the error is "Anonymous function remains at code generation" and on
> top I get "RPC in server-side code"
>
> and I tried like this
> ...
> fun testReR s = return (testRe s)
>
> fun index () =
> r <- testReR "test 123";
> return 
>   
>
> and the error is the same "Anonymous function remains at code generation"
>
> ==
>
> btw, I started another toy project and I seem unable to use curried
> functions due to them resulting in the same error
>
>
> On Wed, Sep 19, 2018 at 9:05 PM Fabrice Leal 
> wrote:
>
>> ok so this was itching me so I decided to try to isolate whatever is at
>> fault. and I think I created the simplest sample to reproduce the problem:
>>
>> https://github.com/fabriceleal/urweb-test
>>
>> so I'm assuming the problem is not at my end and will try to do the
>> parsing on my own until the urweb-regex lib gets updated
>>
>> On Tue, Sep 18, 2018 at 11:01 PM Fabrice Leal 
>> wrote:
>>
>>> I'm having this weird error while trying to compile urweb using
>>> urweb-regex; if I isolate that page in a separate module, it compiles fine
>>> (even though I seem unable to access that page from the browser), so I
>>> assume I'm doing something wrong in my helloworld.ur file.
>>>
>>> Would appreciate some pointers; Source file is this one (
>>> https://github.com/fabriceleal/urweb-experiments/blob/doesnt_compile/helloworld.ur#L869)
>>> and I also included the result of -dumpVerboseSource (
>>> https://github.com/fabriceleal/urweb-experiments/blob/doesnt_compile/dumpVerboseSource.txt#L7705
>>> )
>>>
>>> That FFI maybe_onload is particularly suspicious ... is the call to
>>> parsePgn being "lifted" to javascript code? Some time ago I had some errors
>>> while trying to use the rpc function in the loadPost page because i was
>>> mixing it with code that uses my canvas library which has a bunch of
>>> clientOnly FFI calls; I reorganized my code and eventually made it work
>>> nicely (
>>> https://github.com/fabriceleal/urweb-experiments/commit/503da7e28f1a05be6e69e9f60c9cd321bfa252ce
>>> IIRC). I tried to isolate the testParse function but seems to not lead
>>> anywhere.
>>>
>>> Sorry for the wall of text and thanks in advance :)
>>>
>>> --
>>> ---
>>> Fabrice Leal
>>>
>>
>>
>> --
>> ---
>> Fabrice Leal
>>
>
>
> --
> ---
> Fabrice Leal
> ___
> Ur mailing list
> Ur@impredicative.com
> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>
___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

Re: [Ur] Forms that call rpc instead of redirect

[Aistis Raulinaitis]

Artyom. Not Yartom. I appologize. Thats what happens when you don't double
check your names!

On Feb 12, 2018 17:57, sheganin...@gmail.com wrote:

Thank you Ziv and Yartom!

Ziv, I'll take some time to see if I can get your example working with what
I have. This would be nice to get working.

Yartom, your snapshot function looks very close to what I need. Monad.mapR
is a function I should probably start using more. Thanks!

On Feb 11, 2018 21:31, "Artyom Shalkhakov" <artyom.shalkha...@gmail.com>
wrote:

Hello Aistis,

2018-02-12 4:03 GMT+06:00 Aistis Raulinaitis <sheganin...@gmail.com>:

> Yes I did get a little demo working with ctextbox, cchecbox, and the like.
> However the result is much more verbose and more likely to have runtime
> errors over a regular form.
>
> The way that a form will pack all of its contents into a stuct is a clear
> advantage over the source based route. It requires defining possibly many
> sources and wiring them all into the right slots, having to call "get" on
> each one of them in the onclick handler and then wire all the gotten values
> into the handler.
>
>
FWIW, you can define something like this:

https://github.com/ashalkhakov/urweb-projects/blob/master/meter/screens.ur#
L163

and then use it like this:

https://github.com/ashalkhakov/urweb-projects/blob/master/meter/screens.ur#
L192

And it's not too bad.


> Losing the form submit struct typing mechanism and the added verbosity of
> all the sources would be very painful if you are expecting the majority
> of your forms to be of this style. Which I am.
>
> On Feb 11, 2018 13:20, "Adam Chlipala" <ad...@csail.mit.edu> wrote:
>
>> I think that kind of form has gone out of style, and I personally almost
>> always use the Ur/Web tags like  to collect data and then choose
>> RPCs programmatically.
>>
>> On 02/11/2018 04:10 PM, Aistis Raulinaitis wrote:
>>
>>> The form mechanism is excellent, with the built in type checking, but
>>> the submit action function returns a page: state -> transaction page.
>>>
>>> Is there such a thing such as a version of forms that has a submit
>>> action function with a type of: state -> transaction unit.
>>>
>>> This is so I can call rpc functions there in the submit action and then
>>> the current page is updated using responses over a channel from the server.
>>>
>>
>>
>> ___
>> Ur mailing list
>> Ur@impredicative.com
>> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>>
>
> ___
> Ur mailing list
> Ur@impredicative.com
> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>
>


-- 
Cheers,
Artyom Shalkhakov

___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

Re: [Ur] Forms that call rpc instead of redirect

[Aistis Raulinaitis]

Thank you Ziv and Yartom!

Ziv, I'll take some time to see if I can get your example working with what
I have. This would be nice to get working.

Yartom, your snapshot function looks very close to what I need. Monad.mapR
is a function I should probably start using more. Thanks!

On Feb 11, 2018 21:31, "Artyom Shalkhakov" <artyom.shalkha...@gmail.com>
wrote:

Hello Aistis,

2018-02-12 4:03 GMT+06:00 Aistis Raulinaitis <sheganin...@gmail.com>:

> Yes I did get a little demo working with ctextbox, cchecbox, and the like.
> However the result is much more verbose and more likely to have runtime
> errors over a regular form.
>
> The way that a form will pack all of its contents into a stuct is a clear
> advantage over the source based route. It requires defining possibly many
> sources and wiring them all into the right slots, having to call "get" on
> each one of them in the onclick handler and then wire all the gotten values
> into the handler.
>
>
FWIW, you can define something like this:

https://github.com/ashalkhakov/urweb-projects/blob/master/meter/screens.ur#
L163

and then use it like this:

https://github.com/ashalkhakov/urweb-projects/blob/master/meter/screens.ur#
L192

And it's not too bad.


> Losing the form submit struct typing mechanism and the added verbosity of
> all the sources would be very painful if you are expecting the majority
> of your forms to be of this style. Which I am.
>
> On Feb 11, 2018 13:20, "Adam Chlipala" <ad...@csail.mit.edu> wrote:
>
>> I think that kind of form has gone out of style, and I personally almost
>> always use the Ur/Web tags like  to collect data and then choose
>> RPCs programmatically.
>>
>> On 02/11/2018 04:10 PM, Aistis Raulinaitis wrote:
>>
>>> The form mechanism is excellent, with the built in type checking, but
>>> the submit action function returns a page: state -> transaction page.
>>>
>>> Is there such a thing such as a version of forms that has a submit
>>> action function with a type of: state -> transaction unit.
>>>
>>> This is so I can call rpc functions there in the submit action and then
>>> the current page is updated using responses over a channel from the server.
>>>
>>
>>
>> ___
>> Ur mailing list
>> Ur@impredicative.com
>> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>>
>
> ___
> Ur mailing list
> Ur@impredicative.com
> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>
>


-- 
Cheers,
Artyom Shalkhakov

___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

Re: [Ur] Forms that call rpc instead of redirect

[Aistis Raulinaitis]

Well I'm hoping to be able find some kind of happy middle between spurious
reloads and verbosity of form definition.

I'm fine with implementing a few abstractions myself, I'm just not sure
what the correct direction is.

Your widget system based on ML modules and functors is very interesting I'm
just wondering how it would be possible to achieve what I'm attempting to
do with as little friction as possible.

On Feb 11, 2018 16:16, "Adam Chlipala" <ad...@csail.mit.edu> wrote:

> Maybe just stop worrying about it, so that you might find that problems
> don't arise in practice? >:)
>
> On 02/11/2018 07:13 PM, Aistis Raulinaitis wrote:
>
> Any pointers to get me started on the right path when it comes to a more
> effective usage of source based forms?
>
> On Feb 11, 2018 16:09, "Adam Chlipala" <ad...@csail.mit.edu> wrote:
>
>> I'm not sure what to suggest.  No, there is no existing feature like what
>> you suggest.  I have found it quite pleasant to work with sources and
>> widgets connected to them.
>>
>> On 02/11/2018 05:03 PM, Aistis Raulinaitis wrote:
>>
>> The way that a form will pack all of its contents into a stuct is a clear
>> advantage over the source based route. It requires defining possibly many
>> sources and wiring them all into the right slots, having to call "get" on
>> each one of them in the onclick handler and then wire all the gotten values
>> into the handler.
>>
>>
>
> ___
> Ur mailing list
> Ur@impredicative.com
> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>
>
___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

Re: [Ur] Forms that call rpc instead of redirect

[Aistis Raulinaitis]

The impetus for this style is that I am writing a card game with urweb and
I would rather not redirect back to the game view page for each form the
user must submit.

On Feb 11, 2018 14:03, "Aistis Raulinaitis" <sheganin...@gmail.com> wrote:

> Yes I did get a little demo working with ctextbox, cchecbox, and the like.
> However the result is much more verbose and more likely to have runtime
> errors over a regular form.
>
> The way that a form will pack all of its contents into a stuct is a clear
> advantage over the source based route. It requires defining possibly many
> sources and wiring them all into the right slots, having to call "get" on
> each one of them in the onclick handler and then wire all the gotten values
> into the handler.
>
> Losing the form submit struct typing mechanism and the added verbosity of
> all the sources would be very painful if you are expecting the majority
> of your forms to be of this style. Which I am.
>
> On Feb 11, 2018 13:20, "Adam Chlipala" <ad...@csail.mit.edu> wrote:
>
>> I think that kind of form has gone out of style, and I personally almost
>> always use the Ur/Web tags like  to collect data and then choose
>> RPCs programmatically.
>>
>> On 02/11/2018 04:10 PM, Aistis Raulinaitis wrote:
>>
>>> The form mechanism is excellent, with the built in type checking, but
>>> the submit action function returns a page: state -> transaction page.
>>>
>>> Is there such a thing such as a version of forms that has a submit
>>> action function with a type of: state -> transaction unit.
>>>
>>> This is so I can call rpc functions there in the submit action and then
>>> the current page is updated using responses over a channel from the server.
>>>
>>
>>
>> ___
>> Ur mailing list
>> Ur@impredicative.com
>> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>>
>
___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

Re: [Ur] Forms that call rpc instead of redirect

[Aistis Raulinaitis]

Yes I did get a little demo working with ctextbox, cchecbox, and the like.
However the result is much more verbose and more likely to have runtime
errors over a regular form.

The way that a form will pack all of its contents into a stuct is a clear
advantage over the source based route. It requires defining possibly many
sources and wiring them all into the right slots, having to call "get" on
each one of them in the onclick handler and then wire all the gotten values
into the handler.

Losing the form submit struct typing mechanism and the added verbosity of
all the sources would be very painful if you are expecting the majority of
your forms to be of this style. Which I am.

On Feb 11, 2018 13:20, "Adam Chlipala" <ad...@csail.mit.edu> wrote:

> I think that kind of form has gone out of style, and I personally almost
> always use the Ur/Web tags like  to collect data and then choose
> RPCs programmatically.
>
> On 02/11/2018 04:10 PM, Aistis Raulinaitis wrote:
>
>> The form mechanism is excellent, with the built in type checking, but the
>> submit action function returns a page: state -> transaction page.
>>
>> Is there such a thing such as a version of forms that has a submit action
>> function with a type of: state -> transaction unit.
>>
>> This is so I can call rpc functions there in the submit action and then
>> the current page is updated using responses over a channel from the server.
>>
>
>
> ___
> Ur mailing list
> Ur@impredicative.com
> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>
___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

[Ur] Forms that call rpc instead of redirect

[Aistis Raulinaitis]

The form mechanism is excellent, with the built in type checking, but the
submit action function returns a page: state -> transaction page.

Is there such a thing such as a version of forms that has a submit action
function with a type of: state -> transaction unit.

This is so I can call rpc functions there in the submit action and then the
current page is updated using responses over a channel from the server.
___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

Re: [Ur] Arrays and maps?

[Aistis Raulinaitis]

I agree, I think arrays are much overused in programming for the most part.
My thoughts on are that these libs should facilitate easier interop with
the existing JS libs rather than as a bedrock for a data structure on the
frontend. On the other hand, I like the idea of a finger tree
implementation. My only question is, since we have the choice, would it be
more appropriate to implement it using modules or type classes? My Haskell
background makes me lean in one direction, but I think it would be
interesting to have both. That being said, I should have the js array
library out in the next day or two. Mind you both of these libs in their
forEach functions call execF twice. So you are invoking the Ur/Web runtime
twice for each element. This shouldn't be too bad depending on the
calculation, but it's something to keep in mind.

On Sun, Jul 23, 2017 at 9:50 PM, Artyom Shalkhakov <
artyom.shalkha...@gmail.com> wrote:

> 2017-07-23 0:15 GMT+06:00 Benjamin Barenblat :
> > On Sat, Jul 22, 2017 at 11:59 AM, Artyom Shalkhakov
> >  wrote:
> >> Is it possible to extend Ur/Web with arrays and maps?
> >
> > If you really want an array, I think you’re stuck with the FFI. However,
> > if you just want a bag and amortized runtimes are good enough, you
> > should implement a finger tree. You lose spatial locality, but finger
> > trees are much more suited to pure languages like Ur. There is also a
> > high-quality BSD-licensed implementation in Haskell* that you can base
> > your work on.
> >
>
> I'm currently doing some exercises here:
>
> https://github.com/ashalkhakov/urweb-projects/blob/master/sam/app.ur
>
> and the next thing I'm going to tackle is a TodoMVC clone (I know that
> a demo is available on the Ur/Web website, but I'd like to implement
> it according to State-Action-Model structuring pattern). This requires
> implementing a client-side "model" for storing TODO items. Typical JS
> applications don't bother and use the built-in arrays. So my idea was
> to go the same route, and then test performance on a big dataset. I'm
> a bit concerned about performance.
>
> I was also thinking that if Ur/Web is missing arrays/maps, then it's a
> good project to tackle.
>
> > On the map front, the traditional functional map construction is a
> > balanced binary tree. This one’s a bit unfortunate, because you lose the
> > amortized O(1) promise that you get from hash tables, and you wind up
> > with amortized O(log n) instead. However, they’re simple to implement
> > and only require an `ord` instance for the keys. If you implement finger
> > trees or arrays, you can use them to build hash tables and hash
> > sets. However, you then have to create a `hashable` type class and all
> > the infrastructure associated with it, so it’s a bit more work. Both
> > binary trees and hash data structures are useful to have, so go for
> > whatever sounds most fun to program.
> >
>
> Thanks! I'll see what I can do about it. It should be a fun exercise
> to implement a finger tree or an RB tree or some such.
>
> >
> > * https://hackage.haskell.org/package/containers/docs/Data-Sequence.html
> >
> > ___
> > Ur mailing list
> > Ur@impredicative.com
> > http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>
>
>
> --
> Cheers,
> Artyom Shalkhakov
>
> ___
> Ur mailing list
> Ur@impredicative.com
> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>
___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

Re: [Ur] About clientOnly

[Aistis Raulinaitis]

Hmm, remodeling it to be similar to the examples you gave doesn't seem to
help. I noticed that none of the types in those examples take type
parameters, maybe that has something to do with the difficulties I'm facing?

On Sun, May 21, 2017 at 8:31 PM, Aistis Raulinaitis <sheganin...@gmail.com>
wrote:

> Thanks!
>
> On Sun, May 21, 2017 at 8:27 PM, Artyom Shalkhakov <
> artyom.shalkha...@gmail.com> wrote:
>
>> 2017-05-22 9:19 GMT+06:00 Aistis Raulinaitis <sheganin...@gmail.com>:
>> > Hmm, that makes sense. Do you have an example of FFI with an abstract
>> type?
>> > I tried to encapsulate the map type with a con, but obviously that does
>> not
>> > work..
>> >
>>
>> Sure, here are two examples:
>>
>> https://github.com/bbarenblat/urweb-regex (in particular, take a look
>> at regex__FFI.urs and the two types [substring_t] and
>> [substring_list_t])
>> https://github.com/ashalkhakov/urweb-storage (shameless plug; in
>> particular, take a look at storage__FFI.urs and the type [storage])
>>
>> > On Sun, May 21, 2017 at 8:10 PM, Artyom Shalkhakov
>> > <artyom.shalkha...@gmail.com> wrote:
>> >>
>> >> 2017-05-22 6:22 GMT+06:00 Aistis Raulinaitis <sheganin...@gmail.com>:
>> >> > So I am working with the JS FFI, however it seems that the clientOnly
>> >> > directive is being ignored.
>> >> >
>> >> > Here is the example code:
>> >> >
>> >> > ~~~
>> >> > main.urp:
>> >> > ~~~
>> >> >
>> >> > ffi js_map
>> >> > jsFunc Js_map.new_map=new_map
>> >> > jsFunc Js_map.new_map_with=new_map_with
>> >> > clientOnly Js_map.new_map
>> >> > clientOnly Js_map.new_map_with
>> >> > benignEffectful Js_map.new_map
>> >> > benignEffectful Js_map.new_map_with
>> >> > jsFile js_map.js
>> >> >
>> >> > main
>> >> >
>> >> >
>> >> > ~~~
>> >> > main.urs:
>> >> > ~~~
>> >> >
>> >> > val main : unit -> transaction page
>> >> >
>> >> >
>> >> > ~~~
>> >> > main.ur:
>> >> > ~~~
>> >> >
>> >> > fun main () =
>> >> > c <- Js_map.new_map_with ((1, 2)::[]);
>> >> > return 
>> >> >
>> >> >
>> >> > ~~~
>> >> > js_map.urs:
>> >> > ~~~
>> >> >
>> >> > con js_map :: Type -> Type -> Type
>> >> >
>> >> > val new_map  : k ::: Type -> v ::: Type -> unit -> transaction
>> >> > (js_map k
>> >> > v)
>> >> > val new_map_with : k ::: Type -> v ::: Type -> list (k * v) ->
>> >> > transaction
>> >> > (js_map k v)
>> >> >
>> >> >
>> >> > ~~~
>> >> > js_map.js:
>> >> > ~~~
>> >> >
>> >> > function new_map () {return new Map ();}
>> >> >
>> >> > function new_map_with (arg) {return new Map (arg); }
>> >> >
>> >> >
>> >> > ~~~
>> >> > So in main.ur, you can see that I am calling this Js code in a C
>> >> > context,
>> >> > instead of getting an error complaining about how it should be
>> called on
>> >> > the
>> >> > client, instead I get this confusing error:
>> >> >
>> >> > urweb main
>> >> > /Users/ace/src/cli_only/js_map.urs:4:75: (to 4:87) Unsupported type
>> >> > constructor
>> >> > Constructor:  FFI(Js_map.js_map_with) FFI(Basis.int) FFI(Basis.int)
>> >> > /usr/local/Cellar/urweb/20170105/lib/urweb/ur/basis.urs:127:23: (to
>> >> > 127:25)
>> >> > Unsupported type constructor
>> >> > Constructor:  FFI(Js_map.js_map_with) FFI(Basis.int) FFI(Basis.int)
>> >> > make: *** [all] Error 1
>> >> >
>> >>
>> >> I got the impression that Ur/Web being a whole-program optimizing
>> >> compiler, the only types being supported for marshalling between FFI
>> >> code and non-FFI code are primitive types and abstract types. I think
>> >> I asked this same question some time ago.
>> >>
>> >> So it looks like you will have to work around this somehow.
>> >>
>> >> >
>> >> >
>> >> > ___
>> >> > Ur mailing list
>> >> > Ur@impredicative.com
>> >> > http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Cheers,
>> >> Artyom Shalkhakov
>> >>
>> >> ___
>> >> Ur mailing list
>> >> Ur@impredicative.com
>> >> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>> >
>> >
>> >
>> > ___
>> > Ur mailing list
>> > Ur@impredicative.com
>> > http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>> >
>>
>>
>>
>> --
>> Cheers,
>> Artyom Shalkhakov
>>
>> ___
>> Ur mailing list
>> Ur@impredicative.com
>> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>>
>
>
___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

Re: [Ur] About clientOnly

[Aistis Raulinaitis]

Thanks!

On Sun, May 21, 2017 at 8:27 PM, Artyom Shalkhakov <
artyom.shalkha...@gmail.com> wrote:

> 2017-05-22 9:19 GMT+06:00 Aistis Raulinaitis <sheganin...@gmail.com>:
> > Hmm, that makes sense. Do you have an example of FFI with an abstract
> type?
> > I tried to encapsulate the map type with a con, but obviously that does
> not
> > work..
> >
>
> Sure, here are two examples:
>
> https://github.com/bbarenblat/urweb-regex (in particular, take a look
> at regex__FFI.urs and the two types [substring_t] and
> [substring_list_t])
> https://github.com/ashalkhakov/urweb-storage (shameless plug; in
> particular, take a look at storage__FFI.urs and the type [storage])
>
> > On Sun, May 21, 2017 at 8:10 PM, Artyom Shalkhakov
> > <artyom.shalkha...@gmail.com> wrote:
> >>
> >> 2017-05-22 6:22 GMT+06:00 Aistis Raulinaitis <sheganin...@gmail.com>:
> >> > So I am working with the JS FFI, however it seems that the clientOnly
> >> > directive is being ignored.
> >> >
> >> > Here is the example code:
> >> >
> >> > ~~~
> >> > main.urp:
> >> > ~~~
> >> >
> >> > ffi js_map
> >> > jsFunc Js_map.new_map=new_map
> >> > jsFunc Js_map.new_map_with=new_map_with
> >> > clientOnly Js_map.new_map
> >> > clientOnly Js_map.new_map_with
> >> > benignEffectful Js_map.new_map
> >> > benignEffectful Js_map.new_map_with
> >> > jsFile js_map.js
> >> >
> >> > main
> >> >
> >> >
> >> > ~~~
> >> > main.urs:
> >> > ~~~
> >> >
> >> > val main : unit -> transaction page
> >> >
> >> >
> >> > ~~~
> >> > main.ur:
> >> > ~~~
> >> >
> >> > fun main () =
> >> > c <- Js_map.new_map_with ((1, 2)::[]);
> >> > return 
> >> >
> >> >
> >> > ~~~
> >> > js_map.urs:
> >> > ~~~
> >> >
> >> > con js_map :: Type -> Type -> Type
> >> >
> >> > val new_map  : k ::: Type -> v ::: Type -> unit -> transaction
> >> > (js_map k
> >> > v)
> >> > val new_map_with : k ::: Type -> v ::: Type -> list (k * v) ->
> >> > transaction
> >> > (js_map k v)
> >> >
> >> >
> >> > ~~~
> >> > js_map.js:
> >> > ~~~
> >> >
> >> > function new_map () {return new Map ();}
> >> >
> >> > function new_map_with (arg) {return new Map (arg); }
> >> >
> >> >
> >> > ~~~
> >> > So in main.ur, you can see that I am calling this Js code in a C
> >> > context,
> >> > instead of getting an error complaining about how it should be called
> on
> >> > the
> >> > client, instead I get this confusing error:
> >> >
> >> > urweb main
> >> > /Users/ace/src/cli_only/js_map.urs:4:75: (to 4:87) Unsupported type
> >> > constructor
> >> > Constructor:  FFI(Js_map.js_map_with) FFI(Basis.int) FFI(Basis.int)
> >> > /usr/local/Cellar/urweb/20170105/lib/urweb/ur/basis.urs:127:23: (to
> >> > 127:25)
> >> > Unsupported type constructor
> >> > Constructor:  FFI(Js_map.js_map_with) FFI(Basis.int) FFI(Basis.int)
> >> > make: *** [all] Error 1
> >> >
> >>
> >> I got the impression that Ur/Web being a whole-program optimizing
> >> compiler, the only types being supported for marshalling between FFI
> >> code and non-FFI code are primitive types and abstract types. I think
> >> I asked this same question some time ago.
> >>
> >> So it looks like you will have to work around this somehow.
> >>
> >> >
> >> >
> >> > ___
> >> > Ur mailing list
> >> > Ur@impredicative.com
> >> > http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
> >> >
> >>
> >>
> >>
> >> --
> >> Cheers,
> >> Artyom Shalkhakov
> >>
> >> ___
> >> Ur mailing list
> >> Ur@impredicative.com
> >> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
> >
> >
> >
> > ___
> > Ur mailing list
> > Ur@impredicative.com
> > http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
> >
>
>
>
> --
> Cheers,
> Artyom Shalkhakov
>
> ___
> Ur mailing list
> Ur@impredicative.com
> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>
___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

Re: [Ur] About clientOnly

[Aistis Raulinaitis]

Hmm, that makes sense. Do you have an example of FFI with an abstract type?
I tried to encapsulate the map type with a con, but obviously that does not
work..

On Sun, May 21, 2017 at 8:10 PM, Artyom Shalkhakov <
artyom.shalkha...@gmail.com> wrote:

> 2017-05-22 6:22 GMT+06:00 Aistis Raulinaitis <sheganin...@gmail.com>:
> > So I am working with the JS FFI, however it seems that the clientOnly
> > directive is being ignored.
> >
> > Here is the example code:
> >
> > ~~~
> > main.urp:
> > ~~~
> >
> > ffi js_map
> > jsFunc Js_map.new_map=new_map
> > jsFunc Js_map.new_map_with=new_map_with
> > clientOnly Js_map.new_map
> > clientOnly Js_map.new_map_with
> > benignEffectful Js_map.new_map
> > benignEffectful Js_map.new_map_with
> > jsFile js_map.js
> >
> > main
> >
> >
> > ~~~
> > main.urs:
> > ~~~
> >
> > val main : unit -> transaction page
> >
> >
> > ~~~
> > main.ur:
> > ~~~
> >
> > fun main () =
> > c <- Js_map.new_map_with ((1, 2)::[]);
> > return 
> >
> >
> > ~~~
> > js_map.urs:
> > ~~~
> >
> > con js_map :: Type -> Type -> Type
> >
> > val new_map  : k ::: Type -> v ::: Type -> unit -> transaction
> (js_map k
> > v)
> > val new_map_with : k ::: Type -> v ::: Type -> list (k * v) ->
> transaction
> > (js_map k v)
> >
> >
> > ~~~
> > js_map.js:
> > ~~~
> >
> > function new_map () {return new Map ();}
> >
> > function new_map_with (arg) {return new Map (arg); }
> >
> >
> > ~~~
> > So in main.ur, you can see that I am calling this Js code in a C context,
> > instead of getting an error complaining about how it should be called on
> the
> > client, instead I get this confusing error:
> >
> > urweb main
> > /Users/ace/src/cli_only/js_map.urs:4:75: (to 4:87) Unsupported type
> > constructor
> > Constructor:  FFI(Js_map.js_map_with) FFI(Basis.int) FFI(Basis.int)
> > /usr/local/Cellar/urweb/20170105/lib/urweb/ur/basis.urs:127:23: (to
> 127:25)
> > Unsupported type constructor
> > Constructor:  FFI(Js_map.js_map_with) FFI(Basis.int) FFI(Basis.int)
> > make: *** [all] Error 1
> >
>
> I got the impression that Ur/Web being a whole-program optimizing
> compiler, the only types being supported for marshalling between FFI
> code and non-FFI code are primitive types and abstract types. I think
> I asked this same question some time ago.
>
> So it looks like you will have to work around this somehow.
>
> >
> >
> > ___
> > Ur mailing list
> > Ur@impredicative.com
> > http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
> >
>
>
>
> --
> Cheers,
> Artyom Shalkhakov
>
> ___
> Ur mailing list
> Ur@impredicative.com
> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>
___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

[Ur] About clientOnly

[Aistis Raulinaitis]

So I am working with the JS FFI, however it seems that the clientOnly
directive is being ignored.

Here is the example code:

~~~
main.urp:
~~~

ffi js_map
jsFunc Js_map.new_map=new_map
jsFunc Js_map.new_map_with=new_map_with
clientOnly Js_map.new_map
clientOnly Js_map.new_map_with
benignEffectful Js_map.new_map
benignEffectful Js_map.new_map_with
jsFile js_map.js

main


~~~
main.urs:
~~~

val main : unit -> transaction page


~~~
main.ur:
~~~

fun main () =
c <- Js_map.new_map_with ((1, 2)::[]);
return 


~~~
js_map.urs:
~~~

con js_map :: Type -> Type -> Type

val new_map  : k ::: Type -> v ::: Type -> unit -> transaction (js_map
k v)
val new_map_with : k ::: Type -> v ::: Type -> list (k * v) -> transaction
(js_map k v)


~~~
js_map.js:
~~~

function new_map () {return new Map ();}

function new_map_with (arg) {return new Map (arg); }


~~~
So in main.ur, you can see that I am calling this Js code in a C context,
instead of getting an error complaining about how it should be called on
the client, instead I get this confusing error:

urweb main
/Users/ace/src/cli_only/js_map.urs:4:75: (to 4:87) Unsupported type
constructor
Constructor:  FFI(Js_map.js_map_with) FFI(Basis.int) FFI(Basis.int)
/usr/local/Cellar/urweb/20170105/lib/urweb/ur/basis.urs:127:23: (to 127:25)
Unsupported type constructor
Constructor:  FFI(Js_map.js_map_with) FFI(Basis.int) FFI(Basis.int)
make: *** [all] Error 1
___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

Re: [Ur] Invalid Link expression

[Aistis Raulinaitis]

Huzzah! This seems to work! Thanks Artyom!

On Wed, May 17, 2017 at 11:01 PM, Aistis Raulinaitis <sheganin...@gmail.com>
wrote:

> So I am trying to pass around a list (string * link) to a function that
> will make the string a clickable link, however I run into this error.
>
>
> fun some () : transaction page = return 
> fun anot () : transaction page = return 
>
> fun link_list (l : list (string * (transaction page))) : xbody =
> 
>   {List.mapX (fn (s,p) => {[s]}) l}
> 
>
> fun main () : transaction page =
> return 
>   
> {link_list (("sm", some ()) :: ("anot", anot ()) :: [])}
>   
> 
>
>
> make -k
> urweb main
> /Users/ace/src/link_test/main.ur:7:44: (to 7:45) Invalid Link expression
> Expression UNBOUND_0
> make: *** [all] Error 1
>
___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur