This is indeed so, A release contains a ./configure whereas the source doesn't.
Create on through autoconf - docs are updated.

I think a lot of people who want to use the latest version from Github don't know how to build because there's no configure file. README should mention that it can be created by autoconf.

I've realised that - I've had several questions on this. However, I still feel
that it's the right thing (TM) to not have ./configure checked in.
It just results in pointless diffs.

Thank you for the kind README. It's very clear now.

Thanks

Maybe you can set default charset to utf8?
There is no indication of charset on files which are requested as plain text.
Or better configurable option for each virtual host.

By default today I don't set it to anything - which implies utf8. (according to the standard)
As for having it a configurable - I don't like that since it would be slightly
inefficient - this is driven today by code that is generated at compile time.

Maybe is possible write app for static files? If you can, please, add it to examples. Thanks.

Hmm, what do you mean by "app for static files" - an appmod application that ships static content ? Check the {page, Page} return value.

See

man yaws_api

{page, Page}

          Make Yaws return a different page than the one being requested.

thanks, i already understood

Is b8c1de1 equivalent?

Hello,
The version that you refer not supports binaries as keys as mine.

Regards.

Ok good, once you guys sort this - I'll take what you have.

Going through old yaws issues - any news here ?

TBBIe any idea ?

Looks reasonable to me, but it does cause a binary to go through the is_string method which it currently doesn't do. From the definition of binary_to_list/1, it looks to me like is_string should always return yes for the output of binary_to_list/1, making that round trip an O(len(B)) waste of time. Although encode_string already costs us O(len(S)) I guess.

Would something like this suffice? (I could be even more minimal, and just take the last hunk of the suggested patch, changing encode_string to encode, but this way it's consistent with the existing code.

diff --git a/src/json.erl b/src/json.erl
index b0c3c63..cddcb00 100644
--- a/src/json.erl
+++ b/src/json.erl
@@ -101,7 +101,7 @@ encode(true) -> "true";
 encode(false) -> "false";
 encode(null) -> "null";
 encode(undefined) -> "null";
-encode(B) when is_binary(B) -> encode_string(binary_to_list(B));
+encode(B) when is_binary(B) -> encode_string(B);
 encode(I) when is_integer(I) -> integer_to_list(I);
 encode(F) when is_float(F) -> io_lib:format("~g", [F]);
 encode(L) when is_list(L) ->
@@ -117,6 +117,7 @@ encode(Bad) -> exit({json_encode, {bad_term, Bad}}).
 %% Encode an Erlang string to JSON.
 %% Accumulate strings in reverse.

+encode_string(B) when is_binary(B) -> encode_string(binary_to_list(B));
 encode_string(S) -> encode_string(S, [$"]).                     % " fix highlight for vim :)

 encode_string([], Acc) -> lists:reverse([$" | Acc]); % " fix highlight for vim :)
@@ -146,6 +147,7 @@ encode_string([C | Cs], Acc) ->
 encode_object({struct, _Props} = Obj) ->
     M = obj_fold(fun({Key, Value}, Acc) ->
        S = case Key of
+           B when is_binary(B) -> encode_string(B);
            L when is_list(L) -> encode_string(L);
            A when is_atom(A) -> encode_string(atom_to_list(A));
             _ -> exit({json_encode, {bad_key, Key}})

Compile-tested only... If it's fine, I can throw together a proper commit with attributions etc fairly quickly, or you're welcome to take it as-is.

Great - patch looks just good, I applied it and pushed,

Ok, works perfectly ...

I asked about this on the erlang list - but no response - from any json hackers.
Anyway - It looked as if this was the right thing - but the link above seems dead.
What shall I do ?

/klacke

Which link is dead? The JSON-RPC specification link works for me still.

I don't see any way to attach patches to this bug tracker, but my changed code looks like:

encode_handler_payload({response, ErlStruct}, ID, RpcType) ->
    StructStr =
        case RpcType of
            json -> json:encode({struct, [ {result, ErlStruct}, {id, ID}, {error, null}]});
            haxe -> [$h, $x, $r | haxe:encode(ErlStruct)]
        end,
    {ok, StructStr}.

I've also got a patch that allows returning { error, ErlStruct } to fill in the error field in json-rpc or return an exception in haxe (untested). From the look of the yaws_rpc module, soap and soap_dime don't pass through this path.

One further enhancement I might play with is trying to catch exceptions coming out of the rpc call, and turn them into error results, so the really dumb python json-rpc client I'm testing with stops barfing on Yaw's 400 error page when its expecting a JSON-RPC result. ^_^

Would it be useful if I were to fork the project for these changes, or post patches to a mailing list or something?

Ok, I applied patch and pushed.
As for more ambitious hacks - by best the far is to git clone the yaws repo and then ask me to pull from your branch,

It's also ok to post patches - I can certainly live with that as well.

Thanks

/klacke

Yeah, this would be good - I guess.

If I get a patch for it - I'll include it.

As I noted in my other comment, the "size" parameter to streaming doesn't make sense because HTTP 1.1 essentially disallows the use of the Content-Length header when employing chunked transfer encoding. So let me ask: why do you think you need the size parameter for streaming?

I have a new alternative streamcontent capability in my local repository that might work perfectly for Comet applications. I'm not going to provide any details at this time because I'm waiting to hear back from Klacke as to whether he finds the proposal acceptable before I push to github (but it might be a few days because I think he's on vacation or traveling or something at the moment).

this is the superseded by feature in 1.85

add streamcontent_from_pid capability to allow direct streaming to socket (steve)

The streamcontent_with_size feature seems like an error to me, so maybe that's why it's not documented. For chunked transfer, which is what streamcontent provides, the HTTP spec (RFC2616) states that a Content-Length header must not be sent if the entity length and the transfer length do not match, which is always the case for chunked transfer. The spec also says that if a Transfer-Encoding header and a Content-Length header are both present, the latter must be ignored. See section 4.4 item 3 of RFC2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4.

I agree, weird feature - don't remember where it comes from.

Don't dare to remove the feature - and closing

Any chance you could copy the errors you got and attach them to this issue?

i'm not positive that the apt package management system would necessarily remove everything that it added when i needed to build-dep yaws because after i got it working i later added other erl-related packages ... i checked back in the Terminal log to see if it was still there, but it was not ... i should have cut and pasted, but at the time i wasn't planning on notifying anyone ... i saw your request for doing so on IRC, so I thought you might want to update the installation wiki on github specifically ... it's probably not that big of a deal after all, certainly not big enough to recreate the environment =) ...

Build deps for yaws are fairly close to those of erlang. Are you suggesting we should maintain a complete list - that's a pretty big and complicated job for all platforms. I'd rather like to ignore this request. Maintaining this for platforms like e.g all bsd's and linuxes is a huge job - that also get's invalidated as new versions of supported oses occur.

i certainly understand that and have no problem with your decision, and furthermore, the answer will still be available in the form of the closed request. Cheers.

I think this is not a bug, but the use of process dictionary should be documented.

This is indeed true,yaws uses the process dict. It's fairly safe to bring along some of the dict entries to the new process and -re-putting them.

Agree - should be documented. Unclear where though ....

Steve - wasn't this something you rambled about some time ago - i.e. the ability to transfer the proc dict to another process through a call in yaws_api.erl ???

Yes, but unfortunately I haven't fixed it yet. I just cleared some other things I was working on so I'll tackle this next.

Would there be any problem to something a bit like:

new_spawn(Fun) ->
     L = get(),
     spawn(fun() ->
                [put(X,Y) || {X,Y} <- L],
                Fun()
           end).

Or is there something complex to take care of? I remember doing something similar to the project I had when I actually needed it.

Each yaws process is created through proc_lib: calls, thus there are a few dict entries that should not be carried over to a new process. In particular $ancestors and $initial_call - apart from that the above code is in principle ok.

closing

Problem1. I can't reproduce - actually it seems to work just fine: This code:

out(_) ->

  {streamcontent_with_timeout, "application/octet-stream", <<"kalle">>, 3000}.

And then

[klacke@krom]~ > telnet krom 8000 Trying 127.0.1.1...
Connected to krom.
Escape character is '^]'.
GET /u.yaws

HTTP/1.1 200 OK
Connection: close
Server: Yaws/1.84 Yet Another Web Server
Date: Thu, 06 Aug 2009 10:03:49 GMT
Content-Type: application/octet-stream

kalle
Connection closed by foreign host.

The "kalle" string get shipped immediately, and then after 3 secs, the connection
gets closed. Also looking at the code, it looks good. the FirstChunk should be
shipped directly.

Problem2.

Yes, clearly a bug. Fixed, thanks.

This has been fixed.

As brunorijsman already pointed out, this is fixed, so I'm closing it.

It would save time and make things easier to fix if you submitted a small test case that duplicates the issue. (This goes for all bug reports.)

What's the purpose of the put() in step 2?

A simple example code is here:
http://rapidshare.com/files/261986777/pd.zip

However, I could not reproduce the crash. Maybe because I have updated to the latest version from the GitHub repository.

I am writing a web framework for Yaws here:
http://github.com/ngocdaothanh/ale

For a request, I use the process dictionary to pass things from a layer to another, before filter -> action -> view -> layout etc.

Things in the process dictionary are designed to be in separate namespaces. Seeing that Yaws also use the process dictionary, I will avoid "yaws" for keys.

Thank you for your response to the bug report.

It's fairly easy to write erlang code that shows the above behaviour. All you need to do is to write a non tail recursive function that loops. I think that's what you did - in your code somwhere. So if you cannot reproduce, I close this.

Thanks

/klacke

I find yaws.tex in the old svn repository. Perhaps someone accidentally deleted it?

Hmm, I don't understand, do you mean that the yaws.tex file was deleted?
Anyway, It's certainly possible to build the docs on macosx provided all the
required doc tools are installed, latex2html, dvips, latex, etc.

The Makefile could be improved though, so that it says something better if the tools aren't there.

You're right, yaws.tex is there. I was judging from the message show above that it was missing, but the error is really caused by trying to make yaws.ps where it's looking for the $(DVIPS) tool and can't find it.

Exactly, and all that is needed is a small fix to the makefile checking
for dvips, etc. I added a check target to the Makefile

I found the same thing independently, have it fixed in my local repository, but haven't yet pushed it.

fixed - I guess

Yep, I fixed this awhile back.

No, they aren't. Look at the variables being set in each test -- each sets a different cache-related config variable to 0 and then runs the test.

Ah! The same thing for module yaws_showarg. :)

yaws_vdir.erl is dead, I removed it. The yaws_showarg.erl is more of an example file. It probably shouldn't reside in the src dir.

I bet it's your LESS flags. Try this.

export LESS=erX

man yaws

No that didn't help I'm afraid.

Ahhh .. you mean when yaws - the webserver - display the man pages. I though you meant the normal, linux man page (tty)

Anyway - it's a local issue at your end somehow. The man pages are produced
as:

                    os:cmd("man  " ++ Page ++ "  | col -b -p -x");

So, do that

3> Page = "yaws".
"yaws" 4> Data = os:cmd("man " ++ Page ++ " | col -b -p -x").

If you get UTF-8 characters then - it's you're LOCALE or something.

Hmmm .... I looked further here. maybe it's wrong to invoke the man program in man.yaws. Maybe it would be better to invoke nroff -man instead.

Yeah you were right, the problem was my locale. It was UTF-8, when I changed it to latin-1 the page displays correctly. One way to fix it would be to simply:
Data = os:cmd("env LC_ALL=en_US.ISO-8859-1 man " ++ Page ++ " | col -b -p -x").
This fixed it for me.

Thanks - good solution, taken.

wow, that came out poorly formatted. Basically, I was just saying that it looks like an incomplete change was comitted

I'm getting the same problem. You can checkout an old commit until it gets fixed.
This worked for me: git checkout -b branch-name b732bd1

I also see the same thing.

Sorry about that - fixed.

Need more info ... to be able to say anything sensible here.

too old

Well - you can't have both. Either an appmod is responsible for all data below /xxx or it isn't.

Steve Vinoski suggested:

Isn't the answer to issue #5 to just have a "for everything else"
out/1 function in the appmod that just does a {page, ...} to tell Yaws
to send the file instead?

And - I think this will work fine.

Either an appmod is responsible for all data below /xxx or it isn't.

I mean: (1) if the path is /xxx/yyy/zzz, Yaws should pass the request to the appmod, (2) if the path is exactly /xxx, Yaws should serve the static file.

Currently, when running on Yaws the Nitrogen web framework (http://nitrogenproject.com/) must use the path /web/yyy/zzz for all dynamic contents. And the /web prefix is ugly.

Regards.

Ok,

Have you tried the {page, Page} suggestion for the top level page ?

{page, Page} works: http://groups.google.com/group/nitrogenweb/browse_thread/thread/c2ce70f696b77c9e

Thanks a lot.

Since {page, Page} works as expected, closing this issue.

OTOH, - and I've my self come across the very same issue discussed in the google group mentioned above. One possible - and light weight solution could be to assign an exception list to an appmod. That way it would be possible to have an appmod for / but let everything under e.g. /static be directly served by yaws.

?

I think that's a good idea.

can't reproduce - no longer valid

This was caused by attempts to clear the cache and try again, infinitely. I've committed regression tests for this scenario as well as the fix.

and adding a comment

Pretty nice!

Indeed, and do you also get en email now that I comment your comment ?

I also got a normal github message.

I concur ;c)

edit:
noticing that I may comment although the issue is closed...