From: Hans-Christian E. <hc...@hc...> - 2010-08-15 20:45:12
|
Hello, if I want, for example, to use a regular expression in a .yaws file, is there a recommended/easy way to cache the compiled version of it to avoid having to recompile it everytime the out/1-function of that .yaws file is called? I.e., something like this: <erl> record(args, {re_name}). init() -> args#{re_name=re:compile(?RE_NAME)}. out(A, args#{re_name=Re_name}) -> Name = postvar(A, "name"), {match, _} = re:run(Name, Re_name). [...] </erl> Thanks, HC |
From: Claes W. <kl...@ta...> - 2010-08-16 08:49:25
|
On 08/15/2010 10:45 PM, Hans-Christian Esperer wrote: > Hello, > > if I want, for example, to use a regular expression in a .yaws file, > is there a recommended/easy way to cache the compiled version of it to > avoid having to recompile it everytime the out/1-function of that > .yaws file is called? > No, not directly anyway. You can obviously do it an other process, that you own (and start). And then pick up the compiled expression from there. /klacke |
From: Hans-Christian E. <hc...@hc...> - 2010-08-16 14:50:43
|
On Mon, Aug 16, 2010 at 10:38:20AM +0200, Claes Wikstrom wrote: > On 08/15/2010 10:45 PM, Hans-Christian Esperer wrote: > > Hello, > > > > if I want, for example, to use a regular expression in a .yaws file, > > is there a recommended/easy way to cache the compiled version of it to > > avoid having to recompile it everytime the out/1-function of that > > .yaws file is called? > > > > > No, not directly anyway. You can obviously do it an other process, > that you own (and start). And then pick up the compiled expression from > there. Do you think it's worth adding this functionality to yaws the way I've described it in my last email? HC |
From: Claes W. <kl...@ta...> - 2010-08-16 18:00:14
|
On 16/08/10 16:50, Hans-Christian Esperer wrote: > > Do you think it's worth adding this functionality to yaws the way I've > described it in my last email? Maybe, but it's quite a lot of work, when OTOH it's really easy to address it locally - i.e in your code. /klacke |
From: Mikael K. <kar...@gm...> - 2010-08-20 18:05:23
|
2010/8/18 Steve Vinoski <vi...@ie...> > On Wed, Aug 18, 2010 at 3:45 AM, Hans-Christian Esperer > <hc...@hc...> wrote: > > On Mon, Aug 16, 2010 at 08:00:05PM +0200, Claes Wikstrom wrote: > >> On 16/08/10 16:50, Hans-Christian Esperer wrote: > >> > >> > > >> > Do you think it's worth adding this functionality to yaws the way I've > >> > described it in my last email? > >> > >> Maybe, but it's quite a lot of work, when OTOH it's really > >> easy to address it locally - i.e in your code. > > > > Ok - so, if I use 10 independent little .yaws files on my webserver, I > > supply 10 '-run "..."'-parameters in the yaws startup script so their > > servers get started in the BG? > > You should really start looking into using appmods, as you seem to be > pushing .yaws pages into areas that appmods can already easily cover. > > --steve > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Erlyaws-list mailing list > Erl...@li... > https://lists.sourceforge.net/lists/listinfo/erlyaws-list > I do not think appmods is a solution in itself. As far as I understand the problem may be divided into to parts. 1. A general request for a cache or key-value store/registry that is provided by the Yaws infrastructure to be used by any application programmers. I think this would a good thing. 2. Some idea how to execute code at compilation time for yaws scripts. For point 1, here is a simple store (will not work in cluster, and not totally failsafe) that can be started from yaws.conf using the runmod directive: runmod = yaws_kv_store yaws_kv_store.erl: -module(yaws_kv_store). -export([start/0, stop/1, set/2, get/1, delete/1]). -define(KV_ETS_TABLE, yaws_kv_store). start()-> A = fun()-> ets:new(?KV_ETS_TABLE,[public,set,named_table]), receive kv_store_stop -> ok end end, proc_lib:spawn(A). stop(Pid)-> Pid ! kv_store_stop. set(K,V)-> ets:insert(?KV_ETS_TABLE,{K,V}). get(K)-> case ets:lookup(?KV_ETS_TABLE,K) of [] -> undefined; X -> element(2,hd(X)) end. delete(K)-> ets:delete(?KV_ETS_TABLE,K). ---- For point 2, it is possible to use the -on_load directive for later versions of Erlang/OTP (R13B03 and onwards). This will make it possible to execute code at load time of the module, not compilation time. yaws script example: <html> <head><title>Test of caching regexp</title></head> <body> <h3>Test of Caching regexp</h3> <p>Precondition is that yaws_kv_store is up and running</p> <p>This module makes use of the new on_load feature in Erlang/OTP (since R13B03)</p> <erl> -on_load(cache_my_regexps/0). cache_my_regexps()-> {ok,MyRe1} = re:compile("Ho$"), %% Local Key for this module, will generate new key for every compile yaws_kv_store:set({?MODULE,my_re1}, MyRe1), %% A more global key, will keep inserted objects to a minimum, %% but risk for mixup between modules. %% yaws_kv_store:set(my_re1, MyRe1), ok. %% Always return ok from an on_load function out(A) -> {match, M} = re:run("HoooHo", yaws_kv_store:get({?MODULE,my_re1})), [{ehtml, [{p,[], "Matched regexp is " ++ io_lib:format("~p",[M])}]}]. </erl> </body> </html> --- Regards Mikael |
From: Mikael K. <kar...@gm...> - 2010-08-24 08:39:19
|
2010/8/24 Claes Wikstrom <kl...@ta...> > On 20/08/10 20:05, Mikael Karlsson wrote: > > > > > <erl> > > -on_load(cache_my_regexps/0). > > > > cache_my_regexps()-> > > {ok,MyRe1} = re:compile("Ho$"), > > > > %% Local Key for this module, will generate new key for every compile > > yaws_kv_store:set({?MODULE,my_re1}, MyRe1), > > > > %% A more global key, will keep inserted objects to a minimum, > > %% but risk for mixup between modules. > > %% yaws_kv_store:set(my_re1, MyRe1), > > > > ok. %% Always return ok from an on_load function > > > > out(A) -> > > {match, M} = re:run("HoooHo", yaws_kv_store:get({?MODULE,my_re1})), > > [{ehtml, [{p,[], "Matched regexp is " ++ > io_lib:format("~p",[M])}]}]. > > </erl> > > > > > Funky stuff Mikael, I didn't know about the on_load feature. > > /klacke > Yess, it is coolish isn't it? Actually, I just found out about it when looking around for solutions to this problem. Now what do you think about Yaws maintaining a simple key-value store for users? Could it be part of the "infrastructure" or is it outside the scope and ought to be provided as an addon? Regards Mikael |
From: Hans-Christian E. <hc...@hc...> - 2010-08-18 07:45:34
|
On Mon, Aug 16, 2010 at 08:00:05PM +0200, Claes Wikstrom wrote: > On 16/08/10 16:50, Hans-Christian Esperer wrote: > > > > > Do you think it's worth adding this functionality to yaws the way I've > > described it in my last email? > > Maybe, but it's quite a lot of work, when OTOH it's really > easy to address it locally - i.e in your code. Ok - so, if I use 10 independent little .yaws files on my webserver, I supply 10 '-run "..."'-parameters in the yaws startup script so their servers get started in the BG? HC |
From: Steve V. <vi...@ie...> - 2010-08-18 13:39:35
|
On Wed, Aug 18, 2010 at 3:45 AM, Hans-Christian Esperer <hc...@hc...> wrote: > On Mon, Aug 16, 2010 at 08:00:05PM +0200, Claes Wikstrom wrote: >> On 16/08/10 16:50, Hans-Christian Esperer wrote: >> >> > >> > Do you think it's worth adding this functionality to yaws the way I've >> > described it in my last email? >> >> Maybe, but it's quite a lot of work, when OTOH it's really >> easy to address it locally - i.e in your code. > > Ok - so, if I use 10 independent little .yaws files on my webserver, I > supply 10 '-run "..."'-parameters in the yaws startup script so their > servers get started in the BG? You should really start looking into using appmods, as you seem to be pushing .yaws pages into areas that appmods can already easily cover. --steve |
From: Claes W. <kl...@ta...> - 2010-08-23 22:08:47
|
On 20/08/10 20:05, Mikael Karlsson wrote: > > <erl> > -on_load(cache_my_regexps/0). > > cache_my_regexps()-> > {ok,MyRe1} = re:compile("Ho$"), > > %% Local Key for this module, will generate new key for every compile > yaws_kv_store:set({?MODULE,my_re1}, MyRe1), > > %% A more global key, will keep inserted objects to a minimum, > %% but risk for mixup between modules. > %% yaws_kv_store:set(my_re1, MyRe1), > > ok. %% Always return ok from an on_load function > > out(A) -> > {match, M} = re:run("HoooHo", yaws_kv_store:get({?MODULE,my_re1})), > [{ehtml, [{p,[], "Matched regexp is " ++ io_lib:format("~p",[M])}]}]. > </erl> > Funky stuff Mikael, I didn't know about the on_load feature. /klacke |
From: Claes W. <kl...@ta...> - 2010-08-24 18:52:51
|
> Now what do you think about Yaws maintaining a simple key-value store > for users? Could it be part of the "infrastructure" or is it outside > the scope and ought to be provided as an addon? Honestly, I think it should reside outside yaws since it´s so incredibly easy to implent outside yaws. -klacke |
From: Mikael K. <kar...@gm...> - 2010-08-25 05:46:04
|
> > Now what do you think about Yaws maintaining a simple key-value store > > for users? Could it be part of the "infrastructure" or is it outside > > the scope and ought to be provided as an addon? > > Honestly, I think it should reside outside yaws since it´s so incredibly > easy to implent outside yaws. > > Yes, it is (for me I would say fairly) easy as many things in Erlang :-), so I won't argue about this. The case against everyone rolling their own stuff is that you do not build infrastructure and maintain isolation between applications, while a common store/registry could provide a foundation for applications to interwork, publish interfaces or whatever - and so you may get "synergetic effects". /Mikael |