2009 -- the year of November. <november-wiki.org> <github.com/viklund/november> <irclog.perlgeek.de/november-wiki> <nopaste.snit.ch>
Set by moderator on 10 February 2009.
00:44 PerlJam joined 01:25 viklund joined 03:31 Tene_ joined 03:33 wayland76 joined 07:34 wayland76 joined 08:45 masak joined 09:45 p6eval joined 10:24 wayland76 joined 10:37 ihrd joined
masak ihrd: oh hai 11:01
ihrd masak: HAI
masak ihrd: have you thought of what you'll be using as a database backend for the MVC stuff in Web.pm? 11:05
for the model part, I mean. 11:06
ihrd files on the start, sqlite or mysql on the end (I hope) 11:07
ruoso porting DBIx::Class to Perl 6 would be a good subject to another grant 11:08
masak ihrd: there is a Perl 6 script in the Parrot repo that does sqlite.
svn.parrot.org/parrot/trunk/exampl...sqltest.p6 11:13
seems it was mysql though, and not sqlite.
wayland76 I'm going to backend my stuff onto XML 11:15
But I may not be using all the layers of Web :)
s/XML/Tree/ :) 11:16
ruoso masak, but I insist that you leave the model part to the end
masak ruoso: ok.
ruoso as well as the view part
masak lunch &
wayland76 ...and maybe the controller too? :)
ruoso wayland76, in fact... the most important part is the dispatch, for starts, so... the controller can be delayed as well ;) 11:20
wayland76 Where do I read about dispatch? 11:23
Does it mean "which (sub)pages are loaded when"? 11:24
ihrd masak: yes, I saw this link
11:33 rkendall joined
ruoso wayland76, github.com/masak/web/blob/master/do...work-roles 11:38
zarah ruoso's link is also tinyurl.com/cn3bhg
wayland76 components, that's the word I was after :) 11:40
thanks ruoso
14:45 ihrd left 15:11 p6eval joined
masak www.hanselman.com/blog/TheWeeklySou...guage.aspx 15:14
zarah masak's link is also tinyurl.com/38x3v2
masak Arc, Seaside and Haskell impress with their brevity.
what's the shortest we can make in Perl 6?
15:15 p6eval joined 15:16 p6eval joined 15:30 Tene joined
ruoso masak, they imply some kind of html generation embedded 16:43
masak ruoso: sure.
ruoso which seems to compromise view/controller separatino
masak ruoso: right.
ruoso which is not a very good idea, imho
masak but we're not _just_ building an MVC framework here.
ruoso right...
but compromising extensibility by coupling things is not a good idea in any case 16:44
masak sometimes what you want is something more like Sinatra.
well, it's like saying that Perl one-liners are bad.
everyone agrees, but sometimes they come in handy.
less to write.
quicker to create.
JFDI. 16:45
structure and orthogonality may come later in a project.
ruoso er... that's the main difference between catalyst and RoR
masak oh? please elaborate,
ruoso RoR makes easy things piece-of-cake and hard things impossible
masak :)
ruoso Catalyst makes easy things slightly more complicated and hard things possible 16:46
masak ruoso: so different frameworks have different complexity sweet spots.
that's not very surprising. 16:47
ruoso that's not what I meant
masak no, I understand that, too.
ruoso some frameworks take dirty shortcuts to provide ease of use in the very most common case
masak my point is, though, that you can't have a framework be both very simple for small things, and very orthogonal for big things.
ruoso compromising extensibility and flexibility
masak sometimes you want one, sometimes the other. 16:48
rkendall Just chipping in with half a cent: Most web-dev seems to be the easy stuff
ruoso masak, what I do think is that having a DSL solves the issue
masak ruoso: oh, did I mention that I don't like the term DSL? :)
I think it's mostly hot air and a buzzword.
ruoso masak, for RoR, that's for sure 16:49
masak I'd prefer if it were replaced with the three or four terms that people really mean when they say it.
ruoso: not just RoR. more or less the whole Ruby world.
16:49 wayland76 joined
masak it's like they have a crush on the very term. 16:49
ruoso but a DSL for Catalyst, for instance, would be very much usefull
masak groans
ruoso because Catalyst has strong semantics support
so a DSL would hide that semantics for the common case 16:50
Tene +1 masak 16:54
masak use.perl.org/~Aristotle/journal/36223
zarah masak's link is also tinyurl.com/cc7uqr
masak Aristotle usually writes refreshing things about 'DSL' as a term. 16:55
use.perl.org/~chromatic/journal/34133 16:56
zarah masak's link is also tinyurl.com/2lf9ta
masak chromatic too.
ruoso: specifically, rejecting the challenge because it would 'compromise view/controller separation' is kind of missing the point, which is to show what your language, along with the right library, can hide away in terms of complexity. 17:00
ruoso masak, I'm not rejecting the challenge
masak ok.
good; for a while it sounded that way. 17:01
ruoso I'm just saying that I'm not sure avoiding controller/view separation for golf purposes might not be a good idea
gah...
let me rephrase
masak be my guest. 17:02
ruoso I'm just saying that I'm not sure loosing controller/view separation for golf purposes is a good idea
masak I'm curious how you arrive at that viewpoint.
specifically, why do you think that the same tool must serve both those who want golfers and those who want an MVC framework?
for me, those two have always been separate tools. 17:03
ruoso s/MVC//
I already worked with non-MVC frameworks as well
masak sure, fair enough.
still, it doesn't even have to be a framework.
ruoso but even in non-MVC, gluing the view in the logic is a bad idea
er
that page was about "frameworks"
masak ruoso: I think that's quite a categorical point of view.
I wouldn't go so far as saying that mixing view and logic is always bad. 17:04
just like goto isn't always bad.
ruoso it's like having prints inside the code to generate the output
masak no, it most decidedly is not. 17:05
that's just creating a strawman.
ruoso or using CGI.pm methods
masak we're here to help the programmer, not to point fingers.
ruoso anyway... as far as a "framework" is concerned, separating the view from the logic is usually the first step 17:06
also, as for code maintainance, the most usual problems arise from bad judgment of where the view/logic barrier is... 17:08
masak ruoso: and you still don't think that you're missing the point of the challenge? :) 17:09
it's about producing a small webapp in a few lines of code.
possibly sacrificing things such as view/model separation. 17:11
ruoso: besides, do you think that the Seaside example mixes view and logic too?
ruoso masak, I don't really understand what "request" and "inform" are 17:12
masak ruoso: neither do I.
my guess is that they produce widgets and text, respectively.
ruoso masak, but seaside takes a hard bet on continuations 17:15
masak indeed.
ruoso which takes them to a different land
masak true.
I'm still impressed.
ruoso and that really solves a completely different set of problems
masak they manage to hide the request/response part of the webapp, which is innovative to say the least. 17:16
ruoso masak, not really inovative...
I wrote a framework that did that in 2001 17:17
perl-oak.sf.net
masak oh, I didn't mean it's a completely new idea.
ruoso the use of continuations is the big deal
masak I just think it's one that doesn't get enough attention.
masak needs to go soonish 17:18
ruoso masak, but take a look on the Reaction work
that mst and the people at shadowcat are doing
masak ruoso: url?
ruoso because seaside is cool, but it neglects completely the fact that URLs are a very important thing in web applications 17:19
specially idempotent URLs
masak ack.
that was my thought as well when seeing a demo of it.
ruoso masak, ask mst for it, I don't remember
masak ok.
that'll have to be tomorrow, though.
logs++
ruoso Reaction takes a similar bet of seaside 17:20
but still being URL aware
masak aha.
interesting.
ruoso it basically conceives an Abstract ToolKit
so you model your application interface
but it's still based on the Catalyst dispatcher 17:21
masak found dev.catalystframework.org/wiki/reaction
gotta go. 17:23
masak waves
moritz_ I've just sent a mail to the list with an idea for a simple, flexible dispatcher 19:23
it seem to be too simple to be true ;-) 19:24
ruoso moritz_, I'm replying to that with where it becomes not so simple at all 19:40
moritz_, as a complement to that reply 19:45
I somehow think that the reduction operator could play some interesting role there
[something] url.split 19:46
then 19:47
multi something(Action::Root $root, 'blog', $blogname) { return Action::Chained('/blog') } 19:49
multi something(Action::Chained $root where { '/blog' }, 'category', $category) { return Action::Chained('/blog/category') }
sorry
multi something(Action::Chained $root where '/blog', 'category', $category) { return Action::Chained('/blog/category') }
moritz_ ruoso: I think that a chained dispatcher, once one is written, can easily be plugged in into "my" system 19:51
anyway, I'll answer on-list
ruoso ok
moritz_, but reduce seems to be an interesting solution to that problem 19:52
moritz_ ruoso: so you have a system in mind where each reduction step knows how to get from one level to the next sub level? 19:55
ruoso no, it returns an identification of which step was realized 19:56
which is then used as input to the next call
muti something('blog', $blogname) { do-something(); return Action::Chained('/blog') }; 19:57
muti something(Action::Chained $parent where '/blog', 'category', $category) { do-something(); return Action::Chained('/blog/category') }; 19:58
moritz_ at the moment I can't wrap my head around that :)
but probably I'm just too tired
ruoso [&something] 'blog', 'myblog', 'category', 'foo';
it will call &something trying to bind as much arguments as possible 19:59
take the result of that and use as the first argumetn with the rest of the list
so, it will first match something('blog', $blogname) 20:00
which returns Action::Chained('/blog')
and then it will call it again with that return and the rest of the list
moritz_ so that each part of the URL can decided how many arguments to use up 20:01
clever
ruoso that's how reduce works, isn't it?
you just need to place two anchors before and after each URL part 20:02
moritz_ ususally not
ruoso one to mark the start
and other to mark the end
moritz_ this scheme requires you to keep state in the reduction function
Tene I have to use django at work, and today I am learning about django forms. For each form, you need a class.
ruoso moritz_, the reduction does it already
Tene So if you want dynamic forms, or generated forms, you have to use the metaclass stuff.
ruoso [+] 1,2,3,4
Tene To dynamically generate a new class.
ruoso will first call 1 + 2
then call 3 + 3
Tene This is an awkward situation.
ruoso then call 6+4
moritz_ ruoso: I understand that... 20:03
ruoso it's the same here
moritz_ but if '/blog' wants three arguments, and '/post' wants two
and all with the same reduction function
ruoso ok, we need a "multi" reduce
moritz_ ok ;-)
ruoso but
I think it might work already
moritz_ Tene: that's not something I'd like to have
ruoso since a multi is just a callable
moritz_ Tene: I'd like to decide myself for what I write a class, and for what not 20:04
Tene Yeah, really.
moritz_ ruoso: one problem with all MMD based approaches is that if the dispatch fails, the error message won't be very good
it'll just tell us "dispatch failed at stage $stage", but not why 20:05
like, missing arguments
or arguments of the wrong type
actually that bothers me a lot
ruoso moritz_, the error message would tell which argumetns it tried
in this case, Action::Chained('/blog'), 'category', 'foo' 20:06
moritz_ yes
ruoso which pretty much tells everything
moritz_ which is equivalent to telling you who far it got
but even if there's only one multi left 20:07
if will just tell you "dispatch failed"
ruoso but that happens in other dispatches as well
moritz_ and not `"category" doesn't accept "foo", because it doesn't match regex $bar"
we can still try to do better ;-)
ruoso but the multi dispatch solution seems much more likely to require a sub-grammar 20:08
moritz_ why? 20:09
ruoso because it is heavily dependent on the return of each candidate
so it's better to generate it 20:10
moritz_ what do you mean by "the return of each candidate"?
ruoso actually I meant "reduction iteration" 20:11
moritz_ in "my" scheme not all candidates iterate
only those that do sub-dispatch 20:12
ruoso yes, I'm talking about the "reduce dispatcher" 20:13
moritz_ ah
ruoso btw... reduce already supports multis ....
otherwise overloading + wouldn't work
moritz_ wait 20:15
when you do @list.reduce: { $^a + $^b }
then the closure does the multi dispatch
not the reduce
@list.reduce: &multisub; doesn't work in rakudo 20:16
ruoso [+] 1,$a,$b,2,3
that calls a multi sub
moritz_ yes, but that only works for operators
not for ordinary subs
ruoso uh?
operators are ordinary subs
or is rakudo cheating?
moritz_ yes, and yes. But not all ordinary subs are also operators. 20:17
ruoso there is no difference between those
moritz_ [&your_sub] doesn't work, to the best of my knowledge
there is
ruoso which difference?
moritz_ an operator also has associativity
a sub does not
(and precedence, for that matter, but that's irrelevant here) 20:18
ruoso moritz_, that's just about parsing
not runtime
moritz_ it's also about runtime
[**] 1..10 works differently than [*] 1..10
because ** has a different associativity than *
the first is 1**(2**(3 ...)), the second is (1*(2*3(...))) 20:19
which is why we use .reduce for subs and [...] for methods
ruoso moritz_, one way or another, you're allowed to define new subs defining associativity... 20:35
moritz_ if they are operators, yes.
ruoso I'm not sure there is this fundamental difference
21:23 szabgab joined 21:58 ruoso joined 22:25 wayland joined 22:37 Tene_ joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!