<shritesh>
It looks fairly simple to implement. I wonder if supporting dynamic build options will be difficult.
<hryx>
oh snap shritesh that could be a fun project
<shritesh>
I got the main commands and options working but I wish there was better documentation. Also, Bash and Zsh do things differently. ugh
<shritesh>
nvm. found good resources. zsh supports bash completions out of the box.
<hryx>
I use fish and might be able to help out with a fish implementation
<scientes>
andrewrk, are you messing with cloudfront? i am getting
<scientes>
An error occurred during a connection to ziglang.org. Cannot communicate securely with peer: no common encryption algorithm(s). Error code: SSL_ERROR_NO_CYPHER_OVERLAP
<hryx>
I'm not seeing that scientes -- just tried with chromium and curl, everything looks fine to me
<hryx>
what client are you using?
<scientes>
Firefox
<hryx>
I assume Firefox supports all modern cipher suites, so that's weird
<scientes>
exactly
<scientes>
like sepr256
<scientes>
and ed25519
<hryx>
Maybe you're being MITM'd by a server that doesn't support any ciphers :O
<presiden>
firefox 68 here, it's fine in here,
<hryx>
scientes maybe check the IP it's trying to reach
<scientes>
ok it was a fluke, works now
<scientes>
holy moley cloudflare has their own signing key
<scientes>
try and catch have way too low of operator precedence
<scientes>
but i realized if you want them to work with error types instead of just functions......
<scientes>
then you have a layering problem
bheads_____ has joined #zig
bheads____ has quit [Ping timeout: 244 seconds]
very-mediocre has joined #zig
schme245 has joined #zig
schme245 has quit [Ping timeout: 255 seconds]
ManDeJan has joined #zig
schme245 has joined #zig
schme245 has quit [Remote host closed the connection]
daurnimator has joined #zig
marmotini_ has joined #zig
neceve has joined #zig
<ManDeJan>
d
<ManDeJan>
I want to read the first 3 bytes of a []const u8 as a u24, so I tried @bytesToSlice(@IntType(false, 3*8), "test string"[0..3]), but this failes with a compiler error noting: u24 has size 4; remaining bytes: 3. Why is a u24 a 4 byte type?
daurnimator[m] has joined #zig
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 245 seconds]
hobomatic has joined #zig
<hobomatic>
hello. this thing seems to crash the compiler and I am not sure how to proceed troubleshooting it: https://github.com/rdlph/ibrokeit
Hejsil has joined #zig
very-mediocre has quit [Ping timeout: 256 seconds]
<daurnimator>
idea: could `zig translate-c` emit @cInclude() calls when it finds an include?
<daurnimator>
i.e. do a "non-deep" translation?
<Hejsil>
daurnimator, I don't think that will be easy. Zig calls clang to get an AST, and at that point, the pp have inlined all includes into the AST
<daurnimator>
Hejsil: has it though? we still get all the macros defined etc...
<Hejsil>
Clang gives you the definitions, but all macros calls and includes have been expanded in the AST
<daurnimator>
hrm okay :(
<Hejsil>
We basically get the AST for 'clang -E'
<daurnimator>
k
<daurnimator>
uh, using the zig build system, how do I include the normal system include dirs?
<daurnimator>
what am I doing wrong here: error: expected type '[*c]const u8', found '[3]u8'
<hobomatic>
i figured out how that code crashed the compiler. well the general tact on unixy systems is to generate the actual so as versioned, and make a symlink without the version for use by consumers that don't care
<hobomatic>
ignore first sentence ^
<daurnimator>
hobomatic: yeah that's the usual scheme for creating system libraries. but system libraries aren't the only use for shared objects...
<hobomatic>
true. and maybe zig should support that, but its also trivial to rename the file after its created
<daurnimator>
hobomatic: true. but that seems like a workaround that shouldn't need to happen IMO
<daurnimator>
it probably also breaks some of the build caching?
<hobomatic>
I have no idea. I meant the installed artifact, not the artifact in the cache
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<hobomatic>
daurnimator: you do get system headers automatically with build.zig when you depend on system libraries. And I have no idea how it translates it to a build-exe command line, but you can also control the exact name of the output artifact. I can see std/build.zig actually constructing the filename from the version.
<hobomatic>
build-lib command line^
marmotini_ has joined #zig
<daurnimator>
hobomatic: it does that so it knows where you find the artifact afterwards
<hobomatic>
oh, yeah i guess that would make sense
marmotini has quit [Ping timeout: 245 seconds]
<hobomatic>
strangely, there is a switch that looks at the properties 'self.major_only_filename' and 'self.name_only_filename', which would imply if its only using it to find the filename, then you can omit those when generating the output
<hobomatic>
so I am still convinced its in there somewhere
marmotini has joined #zig
<hobomatic>
have you tried just omitting the semver flags?
marmotini_ has quit [Ping timeout: 246 seconds]
<hobomatic>
yeah i guess you have
neceve has quit [Remote host closed the connection]
<hobomatic>
yeah, that code is for creating the symlinks automatically, which I think is part of the install step for shared libraries
<tgschultz>
ManDeJan: because u24 has alignment 4, arrays care about alignment, and zig defines @sizeOf(T) such that array members are @sizeOf(T) appart. You can read more about that here: https://github.com/ziglang/zig/issues/1851
<ManDeJan>
tgschultz: Thank you :), that makes sense
<tgschultz>
I think mem.readInt or one of its variants may work for your case
hobomatic has quit [Remote host closed the connection]
<scientes>
ManDeJan, because that is its ABI size
<scientes>
ManDeJan, also, you can't do it like that without using Zig's endianness features
<scientes>
actually no, endianness isn't a problem there
brakmic has joined #zig
brakmic has quit [Client Quit]
<daurnimator>
is there a way to make a call with an array of args?
<daurnimator>
like.... passing on a vararg?
<daurnimator>
or just building up a vararg?
<daurnimator>
different question: how can I switch on a type and include lots of different integer widths
<tgschultz>
daurnimator, re: array => arg expansion / varargs pass through isn't possible today, but the removal of varargs in favor of anonymouos struct literals should allow it.
<daurnimator>
tgschultz: essentially I want to build up args for and call an arbitrary function
<tgschultz>
as far as I'm aware there is no way to range a type, you'd have to manually expand it as `i0, i1, i2, i3, i4, i5 => blah,`
<tgschultz>
daurnimator: yeah, cant' be done as far as I know.
<daurnimator>
tgschultz: i0..i63 is a lot of expansion to do
<tgschultz>
daurnimator yeah, but a decent text editor should be able to spit it out for you in a minute or two. The alternative is to switch instead on @typeId and the again on T.bit_count.
<daurnimator>
yeah I think I have to do that
<daurnimator>
tgschultz: is T.bit_count still around? not documented aside from in a few builtins
<daurnimator>
seems to be typeinfo.Int.bits instead now
<tgschultz>
it is. I think the plan is to replace it with `meta.bitCount(T)` but it hasn't been removed yet.
<tgschultz>
see: #2117
<scientes>
yeah bit-count doesn't depend on the type
<scientes>
so no need to check the id first
<scientes>
it would be nice if I could bind values to a function before passing it as a function pointer
<scientes>
do closures do that?
<tgschultz>
bit count does depend on the type: `std.debug.warn("{}", usize(void.bit_count));` => `error: type 'void' does not support field access`
<scientes>
void has 0 bit count
<scientes>
thats the way it is represented in the stage1 compiler
<tgschultz>
what bitcount does std.mem.Allocator have?
<scientes>
@sizeOf() * 8
<scientes>
but yeah, that is a bit funky
<scientes>
for composite types
<tgschultz>
that doesn't make sense. @sizeOf(u24) * 8 is 32.
<tgschultz>
I submit that there's no meaningful bitcount for composite types.
<scientes>
but that is a solution---if it is not clear just use @sizeOf() * 8
<scientes>
u0 are also meaningless, but we have them to make corner cases easier
<tgschultz>
u0 isn't meaningless, it means an unsigned integer with only one possible value that uses no memory at all to represent.
<tgschultz>
I can't think of a case where I'd ever use the bit_count of a struct in a meaningful way.
<scientes>
but back to my question. Closures allow binding parameters to functions?
<scientes>
I have actually never used real closures
<scientes>
I'm just doing quite a bit of copy-paste in my stage1 work
<scientes>
but maybe that is the way c is sometimes
marmotini has quit [Remote host closed the connection]
ManDeJan has quit [Ping timeout: 255 seconds]
forgot-password has joined #zig
<forgot-password>
Anonymous enum literals don't seem to work in arrays, is that intentional?
<forgot-password>
const E = enum { Working, NotWorking };
<forgot-password>
const a: E = .Working; // This Works
<forgot-password>
const b: []E = {.NotWorking}; // This doesn't
<scientes>
forgot-password, looks like a bug, report it
<scientes>
anonymous errors also crash stage1
<scientes>
its a new feature
<emekankurumeh[m]>
anonymous errors are a thing?
<scientes>
not yet
<forgot-password>
scientes: Alright, I'm gonna do that in the evening. Thanks
<scientes>
emekankurumeh[m], but if you try them the compiler crashes
<daurnimator>
error: expected type 'i8', found 'c_longlong'
<daurnimator>
return i8(result);
<daurnimator>
^ what am I doing wrong here?
<scientes>
daurnimator, you need @truncate
<scientes>
or if you know it is small enough @intCast
<daurnimator>
scientes: result *may not* fit in an i8. I want an error/warning to be emitted if it's not.
<scientes>
if you want a run-time error, then you need to check for that
<daurnimator>
Only issue I haven't found a workaround to yet is building up arguments and then doing a call
<scientes>
cool!
<daurnimator>
i.e. line 79 in the gist...
<hedonist>
daurnimator: super cool
<tgschultz>
daurnimator: typeOf(void) should be type.
<daurnimator>
tgschultz: oh right..
Sahnvour has joined #zig
Ichorio has joined #zig
meheleventyone has joined #zig
<meheleventyone>
hey all, with the new wasm target working from the off with 0.4.0 should I expect a build script setup to build an executable (say through zig init-exe) to work if I use setTarget to specify things correctly
<andrewrk>
meheleventyone, are you asking if you can execute a wasm executable?
<meheleventyone>
nope, in the release notes a wasm blob is created using zig build-exe
<meheleventyone>
I want to setup to build with just zig build
<andrewrk>
addCommand would be addSystemCommand but you should just delete that and rely on zig's wasm linker
<gamester>
I've been trying to get webassembly to work but I see nothing of value in the output file when using wasm2wat to inspect the file. I'll create two "export" functions but the only thing I see is one func named __wasm_call_ctors
<meheleventyone>
thanks
<meheleventyone>
my general thought for a 0.4.0 world would be this?
<andrewrk>
I recommend overriding the output dir or using the install step. zig build is sort of in a transition right now to a new way of doing things
<meheleventyone>
ahhh!
<meheleventyone>
cool will go read and tinker some more, thanks!
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andrewrk>
status quo is problematic from a user experience perspective, will definitely address it this release cycle
<andrewrk>
but we're getting closer to the final result
meheleventyone has joined #zig
<gamester>
andrewrk: Only with build-obj, with build-exe I get "lld: error: ./a.o: undefined symbol: print"
<gamester>
wait what. Please don't tell me I've failed to update my zig 3 times in a row. With zig version I get 0.3
<gamester>
i'm a dumbass, I was one directory off. I put into usr/local instead of /usr/local/bin
<gamester>
sorry andrewrk
<strmpnk>
I've done the same thing. I had 0.3 in my path accidentally far too many times. I need to remove my installation of release builds entirely since master builds are almost always a better choice.
<gamester>
I'm hyped for web assembly. For example it can be used for virus-free 3rd party plugins (if we ignore spectre and all that)! No more viruses through PC game modding.
<hedonist>
gamester: what?
<hedonist>
how would wasm help with the virus problem of the web?
<hedonist>
I'm interested in wasm, but I fail to see how it would accomplish that
<gamester>
hedonist: Your game can support webassembly mods and they'll be sandboxed
<scientes>
but when i saw it was C++ it didn't seem like fun anymore
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<gamester>
ha!
<daurnimator>
andrewrk: great, thanks :)
meheleventyone has joined #zig
meheleventyone has quit [Client Quit]
wootehfoot has quit [Read error: Connection reset by peer]
wootehfoot has joined #zig
very-mediocre has joined #zig
meheleventyone has joined #zig
<Sahnvour>
so, I'm writing a hashmap (and later a set of other containers) in the hope that they become good enough to be cherry-picked by zig's std
<Sahnvour>
am I overlapping with someone else's effort, should I discuss this (goals, API ...) in Zig or wait to have something self-contained ?
<Sahnvour>
and "finished"
<andrewrk>
scientes, I have a suggestion for you
<andrewrk>
I know you like to go real fast, and that's cool
<andrewrk>
I think you should have a fork of zig where you just go as fast as you want to, and then send upstream patches at whatever pace I can handle - but not faster than I can handle them
<andrewrk>
these pull requests where you keep pushing unrelated stuff, it actually takes more time for me to review than to do the work myself
<scientes>
yeah that makes sense
<scientes>
Its also about selling the feature and presenting the patch
<andrewrk>
Sahnvour, in general containers are pretty easy to get into the std lib since they are pretty unobtrusive and represent some nice language testing
<scientes>
I wish there was a way where i could run the tests on my own repository
<andrewrk>
with the understanding that the std lib audit will probably remove a lot of things from std (but zig package manager will be available)
<Sahnvour>
how do you feel about the actual API of hashmap for example, would it require a strong rationale to change it or not ?
<andrewrk>
I think it's pretty negotiable
<andrewrk>
also I think that there is room for a hash map that does not support deleting, it can probably optimize differently
<andrewrk>
for example the self hosted compiler uses a lot of hash maps that don't need delete
<companion_cube>
well for a start you can do robin hood hashing more easily
<Sahnvour>
oh yeah, that's totally the direction where I want to go, good default containers and usecase optimized ones
<companion_cube>
no thumbstones
<Sahnvour>
maybe I should start reworking the hashing part of std, there's a TODO in there
<gonzus>
It is rather trivial, but useful nonetheless. However, I realized it doesn't compile on the build machines.
<gonzus>
<3
<gonzus>
Of course, I did compile on my local machine.
<gonzus>
And I do believe the change is worthwhile.
Barabas has quit [Ping timeout: 256 seconds]
<andrewrk>
unfortunately that feature is not available on all the c++ compilers that zig supports, so we can't use it
<gonzus>
So: are we using different C++ compilers?
<andrewrk>
yes, zig supports bootstrapping with MSVC
<gonzus>
MSVC! OMG...
<gonzus>
And I see it failed on other platforms too...
<gonzus>
:-(
<andrewrk>
improving the stage1 compiler in this way is a bit of wasted effort - eventually what we will be shipping will be a self hosted compiler. so for stage1 we are more interested in reliable easy-to-understand code that works on a variety of c++ compilers and versions
<gonzus>
Question: it failed on Mac, where I know for a fact the patch works (with my version of the compiler). Would we consider upgrading the compiler version on some / all platforms?
<gonzus>
Ah. I see.
<hedonist>
ugh
<tgschultz>
There are quite a few "contributor friendly" entries in the issues too if you're looking to get started contributing.
<hedonist>
it's so frustrating that MSVC won't just get over itself and properly implement C
<andrewrk>
it's a tough sell to want to drop compiler support in stage1. bootstrapping is improved with wider c++ compiler support range
<andrewrk>
however in userland, you can use bleeding-edge zig features :)
<gonzus>
Yeah, I see your point. And it makes sense.
<Flaminator>
Well MSVC is a C++ compiler and not a c compiler.
<gonzus>
You want the widest possible audience to bootstrap.
<hedonist>
Flaminator: I'm aware
<hedonist>
Flaminator: another reason they should go away
<gonzus>
tgschultz: will look into those entries
fsateler has quit [Read error: Connection reset by peer]
<andrewrk>
zig will soon be a competitor to MSVC
<andrewrk>
since it ships with a c and c++ compiler and build system
<andrewrk>
and it takes 10 seconds to install rather than 10 hours
<hedonist>
andrewrk: I would happily take zig over VS if I had the option at work
<Sahnvour>
don't be too harsh on MSVC/VS, they are really improving a lot
<andrewrk>
it's true, they recently did a big improvement to linking, inspired from LLD
<hedonist>
Sahnvour: call me radical, but I'm not willing to do anything but be harsh with regards to microsoft
fsateler has joined #zig
<Sahnvour>
well, actually on VS the IDE, you can ... /s
<andrewrk>
hedonist, well you're in the wrong channel then because here in #zig Windows is a Tier 1 Supported platform
<hedonist>
andrewrk: I'm happy to leave that politics alone, and I don't mind that Zig supports Windows as Tier 1
<hedonist>
as long as I don't need to use windows to use zig, I'll be happy :)
<andrewrk>
sounds like everyone can be happy :)
<hedonist>
haha
<Sahnvour>
there's a ton of reasons to not like microsoft and I agree, however I see their compiler being trashed to much for sometimes no reason
<hedonist>
andrewrk: am I right in reading that you're a generally cheerful person? :)
<hedonist>
from the talks I've seen you give, and the comments I've seen you post, you strike me as a generally kind and loving person
<hedonist>
which is rather amazing and wonderful
<Flaminator>
Does Zig currently or possibly in the future support fixing variables/structs to memory locations? It gets used a lot in the embedded world.
<andrewrk>
Flaminator, isn't that the same thing as global variables?
<hedonist>
andrewrk: are global variables not subject to ASLR?
<hedonist>
(or did I misread what Flaminator was asking?)
<hedonist>
Flaminator: tangential aside: are you someone that flames things, or someone that laminates F?
<andrewrk>
if I remember correctly ASLR is done by the operating system not userland. so in an embedded context, if ASLR was happening it would be intentional
<hedonist>
andrewrk: afaik, it's definitely kernel-bound. But, I read Flaminator's question as being something like “is there a way to guarantee a physical memory address for a particular variable supported first-class by Zig?”
<hedonist>
that could, very well, be my misinterpretation
<Flaminator>
Yes that is what I meant, on the chips we program (pic16,pic18) A lot of things are predefined to be in a certain memory location.
<andrewrk>
oh I see. use @intToPtr
<andrewrk>
packed structs and extern structs will probably also come in handy
very-mediocre has quit [Quit: Page closed]
gonzus has quit [Ping timeout: 256 seconds]
<tgschultz>
so this is odd... a test I had was failing (for perfectly legitimate reasons), but reports 2 sources for the error.
<daurnimator>
am I correct in thinking that .get() only reads the key; while .put() takes ownership/assumes lifetime?
<daurnimator>
for non-trivial keys, that makes .getOrPut very dangerous.
Ichorio has quit [Ping timeout: 245 seconds]
<Sahnvour>
daurnimator what do you mean takes ownership ?
<andrewrk>
Sahnvour, I think I spoke too soon about compiler_rt.setXmm0. it seems the libcalls that llvm emits do not respect the windows x64 ABI
Ichorio has joined #zig
<Sahnvour>
andrewrk libcalls meaning llvm-inserted call to eg. `__muloti4` ?
<daurnimator>
Sahnvour: meaning that .internalPut takes a copy of the key; if the key is just a pointer/slice, then you have a footgun
<andrewrk>
yes
<andrewrk>
without the setXmm0 hack, when I call @divTrunc on windows I incorrectly get 0 for one test case, but when calling __divti3 directly it works fine
<Sahnvour>
aww
<Sahnvour>
daurnimator what would you expect instead ? that's the deal with POD right ?
<andrewrk>
Sahnvour, for -target x86-64_windows we emit: define i128 @__divti3(i128, i128)
<andrewrk>
wouldn't we expect to emit instead: define void @__divti3(i128* sret, i128, i128)
<andrewrk>
because "16-byte arguments are passed by reference" and "Any argument that doesn’t fit in 8 bytes, or isn't 1, 2, 4, or 8 bytes, must be passed by reference"
<Sahnvour>
this only tackles arguments
<andrewrk>
ahh
<Sahnvour>
later it says
<Sahnvour>
Non-scalar types including floats, doubles, and vector types such as __m128, __m128i, __m128d are returned in XMM0.
<Sahnvour>
for return values
<daurnimator>
Sahnvour: huh?
<Sahnvour>
if you use a key containing a pointer/slice, you have to copy it into the map, I don't understand what's bothering you
<daurnimator>
Sahnvour: I'm using a HashMap with string keys. the key type is `[]const u8`.
<daurnimator>
Sahnvour: when it copies into the map. it only copies the slice's pointer+len doesn't it?; not the contents?
Ichorio has quit [Ping timeout: 250 seconds]
<Sahnvour>
yes only the slice, that's value semantics
<daurnimator>
Sahnvour: meaning that if you're going to be putting something into a hashmap, you should be making a copy of the key
<andrewrk>
Sahnvour, for `export fn foo() i128 { return 0x1234; }` with `-target x86_64-windows` we would expect it to set %xmm0 to 0x1234, yes?
<Sahnvour>
andrewrk I think so
<Sahnvour>
provided this gets casted correctly
<andrewrk>
we emit this as `define i128 @foo()` and then llvm has it put the value in %eax regardless of the target
<andrewrk>
that seems problematic
<Sahnvour>
hm
<andrewrk>
I don't even know how to specify different behavior to llvm
<andrewrk>
langref says "The C calling convention This calling convention (the default if no other calling convention is specified) matches the target C calling conventions. This calling convention supports varargs function calls and tolerates some mismatch in the declared prototype and implemented declaration of the function (as does normal C)"
<andrewrk>
seems like a bug in llvm...
<Sahnvour>
is it usually useful to compare to what clang emits for equivalent C code ?
<andrewrk>
yes
<andrewrk>
good point. that's how the C ABI tests work
<andrewrk>
the c equivalent of i128 is __int128
hedonist has quit [Quit: WeeChat 2.4]
<andrewrk>
woah, it emits it as define { i64, i64 } @foo()
<andrewrk>
oops, that's for -target x86_64-linux though
<Sahnvour>
do you recall how to put it in cl driver mode ?
wootehfoot has quit [Read error: Connection reset by peer]
<andrewrk>
I'm using `clang -nostdlib -S -emit-llvm test.c -target x86_64-windows`
<andrewrk>
this also does `movl$4660, %eax` same as in zig. hmm
<Sahnvour>
not usable on godbolt anyway :(
<Sahnvour>
andrewrk what does the IR say ?
<andrewrk>
clang gives `define i128 @foo()` for `__int128 foo(void)` with -target x86_64-windows
<andrewrk>
but then when calling __divti3, it expects the return value to be in %xmm0
<andrewrk>
I wonder if this is a clue: typedef int ti_int __attribute__ ((mode (TI)));
<emekankurumeh[m]>
i think that's a regression but i'm not sure
<Sahnvour>
daurnimator the key is the slice, and you are making a copy of it (inside the map). and you probably have to keep a copy of it outside the map to access/remove it if you want to. either way, the actual string does not get copied
<Sahnvour>
I think I'm missing something about your concern
<daurnimator>
andrewrk: ^ note start of http header module :)
<andrewrk>
nice
<andrewrk>
putting headers in a hash map huh? that's a pretty high level abstraction
<andrewrk>
I hope that's built on a lower level one, and has a reasonable default maximum number of header bytes
<daurnimator>
andrewrk: huh? maximum number of header bytes is a higher level abstraction...
<daurnimator>
andrewrk: note that in http 1 vs 2 vs quic, the header wire format is very different.
<andrewrk>
HTTP headers in a hash table with no maximum bytes is an invalid abstraction
<shritesh>
andrewrk: gotcha. It's not being generated in my case. I'll try to come up with a small example.
<andrewrk>
http clients are adversaries
<daurnimator>
andrewrk: all of that is a higher level concern of the developing filling up the headers object
<andrewrk>
shritesh, looks like that functionality is missing from the wasm linker code. you can see the elf linker code for how to do it
<daurnimator>
andrewrk: this same structure is used by e.g. http clients. you e.g. build up a request headers object and serialise it to the wire.
<shritesh>
Ah!
<andrewrk>
daurnimator, I see
<Sahnvour>
daurnimator IIUC, the hashmap will never take ownership of your strings, if you're affraid they will cease to be valid before the map, then yes you'd have to copy their content first and use that
<Sahnvour>
andrewrk good luck with that, sorry I can't help you much on this topic
Sahnvour has quit [Quit: Leaving]
<daurnimator>
andrewrk: a server ends up doing something like: const h = Headers.init(&Request.allocator); ...... while (true) { if (h.count() > self.max_header_lines) return error.TooManyHeaders; const headerline = try http1_stream.readHeaderLine(max_timeout); ....... h.append(headerline.name, headerline.value, null); }