Re: [go-nuts] time.ParseDuration does not accept scientific notation

[Scott Pakin]

On Friday, April 26, 2024 at 6:08:02 PM UTC-6 Ian Lance Taylor wrote:

The first step would be to open a proposal for this change. See 
https://github.com/golang/proposal#readme. Thanks. 


Done: proposal: time: allow scientific notation in ParseDuration 
.

Thanks for the link. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6e381542-3184-42a3-b647-07397786be38n%40googlegroups.com.

[go-nuts] time.ParseDuration does not accept scientific notation

[Scott Pakin]

While parsing output from some third-party program, I discovered that 
time.ParseDuration  does not accept 
inputs expressed in scientific notation even though strconv.ParseFloat 
 does accept such inputs. Here’s an 
playground example demonstrating this limitation: 
https://go.dev/play/p/G-1FveHxpZ3. 

Any chance ParseDuration could be enhanced to accept the same numerical 
values as ParseFloat?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9db5c71a-581f-4dee-b8ab-6828b15972a9n%40googlegroups.com.

[go-nuts] godoc formatting of example test

[Scott Pakin]

It seems godoc doesn't honor much formatting when rendering function 
comments for Example functions.  In particular, it rewraps text that I 
consider preformatted.  For example,

// This is an example:
//
//foo
// bar
//  baz
//
// Why does godoc wrap those lines in examples?
func ExampleHello() {
Hello()
}

produces:
[image: godoc-formatting.png]
I used the same text for the Hello function itself in the above to show 
what formatting I was hoping to see.

Is this behavior intentional or an oversight?  If the latter, is it 
something the godoc developers would be willing to fix?

Thanks,
— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/953f978c-03aa-4361-9bc7-cfe36cf650ecn%40googlegroups.com.

Re: [go-nuts] Implementation of image.NRGBA64

[Scott Pakin]

Thanks for the response.  It strikes me that the primitive NRGBA operations 
(get pixel, set pixel, and the like) would occur far more common in 
practice than encoders, decoders, compress/*, and io, but maybe that's just 
how I tend to use images.

On Tuesday, September 28, 2021 at 5:02:48 PM UTC-6 Nigel Tao wrote:

> On Tue, Sep 28, 2021 at 3:53 AM Scott Pakin  wrote:
>
>> I'm curious: Why does image.NRGBA64 define Pix as a []uint8 and 
>> perpetually pack pairs of uint8 values into a uint16?  Wouldn't it have 
>> been easier and faster to define Pix as a []uint16 and Stride to be a 
>> stride in uint16s rather than uint8s?
>
>
> It would have been easier for some things, but it would make it harder to 
> work with the encoders and decoders. The compress/* and io packages work 
> with []uint8, not []uint16.
>
> There didn't seem to be perfect solution, only trade-offs.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/127da67d-5fd2-4ad7-8049-9189a9542f88n%40googlegroups.com.

[go-nuts] Implementation of image.NRGBA64

[Scott Pakin]

I'm curious: Why does image.NRGBA64 define Pix as a []uint8 and perpetually 
pack pairs of uint8 values into a uint16?  Wouldn't it have been easier and 
faster to define Pix as a []uint16 and Stride to be a stride in uint16s 
rather than uint8s?

— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/549ef9cf-8684-4d4c-a3bc-e2f0ee3dede5n%40googlegroups.com.

[go-nuts] Re: Query on using Closures

[Scott Pakin]

Just a guess: You may need to make a local copy of index inside your loop 
because index gets overwritten each iteration.

On Sunday, June 6, 2021 at 12:45:01 PM UTC-6 Suveetha Kamatchi wrote:

> Hi team 
> I am a newbie to golang. 
> I am writing a code that does transactions in postgres.
> The list of queries to be executed under one transaction is gathered 
> across multiple handler code.
>
> The way I am maintaining the query structure is as follows
>
> type TxQuery struct {
>function TxFunc
>data types.TransactionData
> }
> type TxFunc func(tx *sqlx.Tx, input types.TransactionData) error
>
> var TxQueries []TxQuery
>
> func getHandlerInput() []TxQuery {
>
> // fill with your set of DDL/DML queries.
>
> }
>
> txQueries := getHandlerInput(db.DB)
>
> tx := db.DB.MustBegin()
>for index, _ := range txQueries {
>fmt.Println(txQueries[index].function, txQueries[index].data)
>err = txQueries[index].function(tx, txQueries[index].data)
>assert.Nil(t, err)
> }
>
> err = tx.Commit()
>
>
> The issue I am facing is 
> The function always retains the last assigned closure for all the data in 
> the list i.e previous values of function gets overwritten.
>
> i.e the last query command gets executed twice with first and second 
> argument list. 
>
> Logs:
> 2021/06/04 18:43:40 Added marketplace escrow  entry for 
>  {---- 
> 141b147a-96ab-4dda-a4f6-d142e7e04a97 6789 8 2 1000 255 15 7 7 7 {"wallex"} 
> 282 283 284 false   0001-01-01 00:00:00 + UTC 0001-01-01 
> 00:00:00 + UTC 0001-01-01 00:00:00 + UTC 0001-01-01 00:00:00 + 
> UTC 0001-01-01 00:00:00 + UTC 0001-01-01 00:00:00 + UTC}
> 2021/06/04 18:43:40 Added marketplace escrow  entry for 
>  {---- 2f2fe301-8545-4030-940c-c32937392034 
>  6f2c68ab-ab84-46b6-b70b-6ec5c0205e09 {"project": "software"} 
> 141b147a-96ab-4dda-a4f6-d142e7e04a97 6789 8 2 1000 255 15 7 7 7 {"wallex"} 
> 282 283 284 false   0001-01-01 00:00:00 + UTC 0001-01-01 
> 00:00:00 + UTC 0001-01-01 00:00:00 + UTC 0001-01-01 00:00:00 + 
> UTC 0001-01-01 00:00:00 + UTC 0001-01-01 00:00:00 + UTC}
>
> Please let me know what I am missing?
>
> Thanks, 
> K.R.Suveetha Kamatchi
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a18e4053-fc7c-4921-a60a-b3e4f3c6d76cn%40googlegroups.com.

Re: [go-nuts] Operator precedence

[Scott Pakin]

Axel and Keith: Thanks for responding.  I'm glad it sounds like I'm reading 
the spec correctly—and that Go shouldn't do anything sneaky with evaluation 
order.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/999592f8-4a06-4f59-a523-e1368f19448fn%40googlegroups.com.

Re: [go-nuts] Operator precedence

[Scott Pakin]

Alex and Keith: Thanks for responding.  I'm glad it sounds like I'm reading 
the spec correctly—and that Go shouldn't do anything sneaky with evaluation 
order.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/16c049ec-7ed2-46d0-8be8-4d89c3943f4fn%40googlegroups.com.

[go-nuts] Operator precedence

[Scott Pakin]

When the Operator precedence 
 section of the language 
specification says that "Binary operators of the same precedence associate 
from left to right. For instance, x / y * z is the same as (x / y) * z", 
does this imply that the language guarantees that a*3.0/2.0 will always be 
evaluated as (a*3.0)/2.0 and never as a*(3.0/2.0), even though the constant 
expression can be computed at compile time?  Does this hold for integer 
types, too (e.g., a*3/2)?

Thanks,
— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4f64105d-7ecb-4cf8-a18f-d045ace5e9ecn%40googlegroups.com.

[go-nuts] Re: Compiler treatment of infinite loops

[Scott Pakin]

On Friday, March 5, 2021 at 8:20:36 AM UTC-7 Brian Candler wrote:

> There is a flip side to that: if you add the return statements, then 
> ForLoop1() gives an error due to unreachable code!
> https://play.golang.org/p/0bajnJWTz7U
>
> So you can't win either way.  I think this implies that if the behaviour 
> were changed now, it would break the go compatibility promise.
>

The Go developers might want to comment on this, but my interpretation of 
the Go compatibility promise is that working programs won't break, not that 
programs that fail to compile will suddenly compile.  So I think we're safe 
there.

I don't know if it makes any difference, but the "unreachable code" 
complaint is coming from go vet, not the compiler proper.

Still, you make an interesting observation.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a2f2a9b8-cdc6-48d2-9cfe-7204d219255dn%40googlegroups.com.

[go-nuts] Compiler treatment of infinite loops

[Scott Pakin]

The Go compiler (I'm using go1.16 linux/amd64) correctly infers that 
function with an infinite for { … } loop that conditionally returns a value 
from within the loop does not also need to return a value at the end of the 
function:

   - https://play.golang.org/p/07ZjFx2uJlx

However, changing that infinite loop to a three-clause for loop with true 
as the continuation condition (e.g., for i := 0; true; i++ { … }) complains 
about a missing return at end of function:

   - https://play.golang.org/p/yf4ihkdBUXZ

Shouldn't the compiler treat those two cases the same?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/be12d501-8ab7-4057-9529-76f420de345cn%40googlegroups.com.

[go-nuts] [ANN] New Go package: xmorph

[Scott Pakin]

It's perhaps a bit of a niche tool, but I just released *xmorph*, a package 
for warping and morphing images.  The code is available from

https://github.com/spakin/xmorph

(If nothing else, you can see there my crude attempt at morphing the 
cartoon Go gopher into the corresponding plush toy.)

The Go package is essentially a wrapper for the C libmorph library (
http://xmorph.sourceforge.net/), which is what the morph CLI and the xmorph 
and gtkmorph GUIs build upon.

Enjoy!

— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9e89e277-8e36-45e0-97a0-098dce8b908en%40googlegroups.com.

Re: [go-nuts] It is said that future Macs will use ARM, is golang ready for this move ?

[Scott Pakin]

On Wednesday, June 10, 2020 at 1:24:24 PM UTC-6, David Riley wrote:
>
> This is certainly pedantry, but it's worth noting that the VAX to Alpha 
> translation in VMS wasn't dynamic recompilation, but static.  There are 
> almost certainly similar examples; I'm not familiar enough with NT history 
> to remember if there was a similar translator for the Alpha version, but 
> given that Dave Cutler was at the helm of that transition (though not the 
> VAX->Alpha transition at DEC), I wouldn't be surprised. 
>

While we're off-topic anyway, I do recall hearing a nifty talk 20+ years 
ago on semi-static translation from x86 to Alpha, both under Windows NT, 
that DEC implemented.  They were worried about the dearth of Windows 
NT/Alpha software relative to the volumes of Windows NT/x86 software so 
translation made a lot of sense.  I recall the speaker making a point that 
PowerPoint posed a challenge for them because their tool looked for known 
compiler code-generation patterns that they could exploit for performance 
(correctness?), but at the time, PowerPoint was hand-coded in assembly 
language.  Imagine!

— Scott

P.S.  I just checked, and amazingly, the paper is still on the Web: DIGITAL 
FX!32 Running 32-Bit x86 Applications on Alpha NT 


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5870abde-8141-4402-b964-95f1feb4240fo%40googlegroups.com.

Re: [go-nuts] Why isn't there "number plus" postfix syntax for more than or equal?

[Scott Pakin]

On Friday, April 24, 2020 at 8:44:46 AM UTC-6, Michael Jones wrote:
>
> That feels clearer to me. Both concepts are now made explicit. The 
> language Pascal has ranges and a membership clause. ADA also embraced some 
> of it. We could imagine:
>
> a in 99..
> a in 99..123
>
> The “in” part feels important to me. 
>

Python's chained comparison operators are arguably more compatible with the 
existing Go syntax and semantics, though:

99 <= a <= 128

— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2ee97826-38a2-4dec-8d94-73559020301d%40googlegroups.com.

[go-nuts] Re: HSV image format

[Scott Pakin]

On Sunday, March 29, 2020 at 11:30:02 AM UTC-6, Scott Pakin wrote:
>
> Does anyone know of a package that provides an image.Image 
> <https://golang.org/pkg/image/#Image> with an HSV color model 
> <https://golang.org/pkg/image/color/#Model>?  I've found lots of 
> functions that convert color models but not a package that puts it all 
> together into an Image interface.
>
> If not, I'll write my own and make it available, but I figured I should 
> first check if someone has already done this.
>

I'll take the lack of responses as a "no".

I went ahead and wrote my own HSV support for Go images.  The resulting 
hsvimage (analogous to image <https://golang.org/pkg/image/>) and 
hsvimage/hsvcolor (analogous to image/color 
<https://golang.org/pkg/image/color/>) are available from GitHub under a 
BSD-3 license:

https://github.com/spakin/hsvimage


This initial release supports only the NHSVA color model 
(non-alpha-premultiplied hue, saturation, and value with alpha channel at 8 
bits per channel) and associated images.  These implement, respectively, 
the color.Model interface <https://golang.org/pkg/image/color/#Model> and 
the image.Image interface <https://golang.org/pkg/image/#Image>.  Caveat: 
HSV↔RGB conversions are slightly lossy due to 360° of hues being 
represented with the numbers 0–255.

Enjoy,
— Scott


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8bc1-a8e5-4c52-82e4-d1a35b78ee90%40googlegroups.com.

[go-nuts] HSV image format

[Scott Pakin]

Does anyone know of a package that provides an image.Image 
 with an HSV color model 
?  I've found lots of functions 
that convert color models but not a package that puts it all together into 
an Image interface.

If not, I'll write my own and make it available, but I figured I should 
first check if someone has already done this.

Thanks,
— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6d0f3862-0713-4bb9-a89c-718f871364be%40googlegroups.com.

[go-nuts] Re: Writing bitmap data to a canvas with WebAssembly

[Scott Pakin]

I figure I ought to follow up with some results.  First, I got the 
suggested approach of local render + js.CopyBytesToJS 
 + update canvas from 
image to work, so thanks, Agniva and Howard!  Second, for the benefit of 
future readers of this thread, one thing that wasn't obvious to me is that 
one needs to render the image data in a browser-recognizable image format—I 
used PNG —*not* 
raw {red, green, blue, alpha} bytes as is needed when writing directly to a 
canvas 's image data.  
Third, I used JavaScript code like the following to update an invisible img 
 then copy the image data from 
there to a visible canvas:

function copyBytesToCanvas(data) {
let blob = new Blob([data], {"type": "image/png"});
let img = document.getElementById("myImage");
img.onload = function() {
let canvas = document.getElementById("myCanvas");
let ctx = canvas.getContext("2d");
ctx.drawImage(this, 0, 0);
};
img.src = URL.createObjectURL(blob);
}

Fourth, the performance is indeed substantially faster than my previous 
approach based on using SetIndex 
 to write directly to 
the canvas, even though the new approach requires the extra steps of 
encoding the image in PNG format and copying the image data from an img to 
a canvas.  The following performance data, measured with Go 1.14 and 
Chromium 80.0.3987.132 on an Ubuntu Linux system, is averaged over 10 runs:

*Old*: 686.9 ± 7.6 ms
*New*: 290.4 ± 4.1 ms (284.3 ± 4.2 on the WebAssembly side plus 6.0 ± 2.3 
on the JavaScript side)

This is the time to render a simple 800×800 gradient pattern.

I hope others find this useful.

— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2465c1d3-9881-404f-a70d-6bee7f8225a7%40googlegroups.com.

[go-nuts] Re: Writing bitmap data to a canvas with WebAssembly

[Scott Pakin]

On Thursday, March 12, 2020 at 1:14:43 PM UTC-6, howar...@gmail.com wrote:
>
> If the  was off-screen or hidden, couldn't you still reference it to 
> get the data into the canvas like:
>   var img = document.getElementById('targetImg');
>   ctx.drawImage(img, 10, 10);
>
> Might not be the most efficient way, but it seems like it should work.
>

 Yes, that definitely sounds like it's worth a shot.

Thanks,
— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7bb51a2b-bbc8-4c7c-851a-6feaaa5be300%40googlegroups.com.

[go-nuts] Re: Writing bitmap data to a canvas with WebAssembly

[Scott Pakin]

On Thursday, March 12, 2020 at 11:35:30 AM UTC-6, Agniva De Sarker wrote:
>
> There is no base64 conversion now anywhere. If you read the code below, 
> you'll see I use 
>
> dst := js.Global().Get("Uint8Array").New(len(s.outBuf.Bytes()))
> n := js.CopyBytesToJS(dst, s.outBuf.Bytes())
> s.console.Call("log", "bytes copied:", strconv.Itoa(n))
> js.Global().Call("displayImage", dst)
>
> Essentially, I copy over the bytes to the array and pass the array over to 
> JS land.
>
> And then displayImage does this:
>
> function displayImage(buf) {
>   let blob = new Blob([buf], {'type': imageType});
>   document.getElementById('targetImg').src = URL.createObjectURL(blob);
> } 
>

I see.  In your case, targetImg is an , right?  Do you know how I 
could use this same technique with a ? 

Thanks for the code.  It's good to see that there's a way to skip base64 
conversions during the Go-to-JavaScript data transfer.

— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/633d160f-4636-40f9-84be-d59af911eedd%40googlegroups.com.

[go-nuts] Re: Writing bitmap data to a canvas with WebAssembly

[Scott Pakin]

Thanks for the links and summaries.  I had actually seen a few of those 
pages before.  The plasma demonstration at least provides some empirical 
evidence that as hacky as it is to convert binary→base-64 ASCII→binary for 
every frame update, the actual performance isn't too terrible.

On Wednesday, March 11, 2020 at 7:22:15 AM UTC-6, howar...@gmail.com wrote:
>
> His final verdict was that the pure Javascript version performed better 
> than the Go-WASM+JS version.
>

…which is not too surprising given the excessive data-format conversions 
and what makes me wonder if there isn't a more direct way—especially in 
newer versions of Go—to pass image data directly between Go and JavaScript.

Regards,
— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/751f1b77-5eee-4463-abeb-2281c153aaed%40googlegroups.com.

[go-nuts] Writing bitmap data to a canvas with WebAssembly

[Scott Pakin]

I'm new to WebAssembly and am trying to get Go to generate a bitmapped 
image to display in the Web browser.  Here's what I've come up with so far:

func DrawPicture(this js.Value, args []js.Value) interface{} {
// Create a canvas on the Web page.
const width = 256
const height = 256
canvas := js.Global().Get("document").Call("getElementById", 
"my-canvas")
canvas.Set("width", width)
canvas.Set("height", height)
canvas.Set("style", "border: thin solid black")
ctx := canvas.Call("getContext", "2d")
ctx.Call("clearRect", 0, 0, width, height)


// Render a picture.
imgData := ctx.Call("createImageData", width, height)
data := imgData.Get("data")
for y := 0; y < height; y++ {
for x := 0; x < width; x++ {
ofs := 4 * (y*width + x)
data.SetIndex(ofs+2, x+y)
data.SetIndex(ofs+3, 255)
}
}
ctx.Call("putImageData", imgData, 0, 0)
return nil
}

My question is: Is SetIndex 
 the most efficient way 
to write the image's pixels?  I see that syscall/js 
 provides a CopyBytesToJS 
 function, but I was 
unable to get that to work because the image data is a Uint8ClampedArray
 and CopyBytesToJS expects a Uint8Array.  I kept trying to populate a Go 
[]byte and transfer that to the image but never succeeded in making that 
work.

Thanks,
— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/78570dbf-9e6e-429b-a776-76ce50f5c7e2%40googlegroups.com.

Re: [go-nuts] Panicking in public API ?

[Scott Pakin]

On Tuesday, January 7, 2020 at 12:47:28 AM UTC-7, Axel Wagner wrote:
>
> Thus, panics are the right tool to use when reporting an issue that 
> requires programmer attention and errors are the right tool when reporting 
> an issue that requires user-attention (or, of course, can be handled 
> programmatically).
>

Nicely presented guideline!

— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5903933e-93c9-4187-ba54-9e9e2b7f1d99%40googlegroups.com.

[go-nuts] Re: ? How restrict usage of packages ?

[Scott Pakin]

On Monday, November 25, 2019 at 9:55:55 AM UTC-7, Daniel Norte Moraes wrote:
>
>I Want create and permite my users to create go lang programs mostly 
> with full capabilities from
> golang itself, but with some direct capabilities as net and filesystem 
> striped from direct accesss; mostly 
> capabilities as database access, and network access will be encapsuled in 
> ours third parthy golang libs :-)
>   The intent is use golang as a full-fledge compiled language and as 
> substitute for a need a custom scripted language.
>

I do something much like that for my Go Server Pages 
 project, which lets one embed Go code in a Web 
page à la PHP.  The Web server administrator can choose which packages are 
allowed to be imported, with the default being only the provided gosp 
package , which 
encapsulates a few functions from some of the standard packages.  Check out 
the gosp2go source directory 
 and in particular 
the ValidateImports method in utils.go 

.

— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d6b3f18b-7abf-4a4f-94fc-02475bd43088%40googlegroups.com.

[go-nuts] [ANN] Go Server Pages

[Scott Pakin]

I'm excited to announce the initial release of

Go Server Pages

Go Server Pages is an Apache module that lets you embed Go code within a 
Web page.  The Go code gets executed dynamically server-side.  Here's a 
quick example:



  
Test of Go Server Pages

  

  
You should https://gosp.pakin.org/;>!
  



When a page like that is served over the network, the client sees the Go 
code replaced with its output:

…

You should https://gosp.pakin.org/;>TRY GO SERVER PAGES 
TODAY!

…

If you're familiar with PHP, it's a lot like that but using Go as the 
programming language and with more thought given to security in the 
implementation.  Here's where to go for documentation and downloads:

Home page: https://gosp.pakin.org/
GitHub repo: https://github.com/spakin/gosp


Enjoy!

— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/91706b87-ae51-4476-87ca-2863154c226f%40googlegroups.com.

[go-nuts] Writing my first Go module

[Scott Pakin]

I've written a package to which I'm about to make an incompatible API 
change.  I figured this would be a good opportunity to learn about Go 
modules.  I think I understand the basics, but there are a few details I'm 
confused about:

First, on the repository side, all I need to do is include go.mod and go.sum 
and tag the commit with v2.0.0, right?  I figure I should probably also 
give the last commit of the old API its own go.mod and go.sum files and tag 
that commit with v1.0.0.

Second, if another user does a non-versioned import "github.com/my/module", 
is it true that they'll get the last pre-2.0 version and if they want the 
new API they have to explicitly import "github.com/my/module/v2"?  Or is 
that the case only if the user's program is also set up for versioning 
(i.e., has go.mod and go.sum files) and that the default is to get the 
latest commit, whatever its version?

Thanks,
— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fbd50494-9484-467f-b235-45b66bb63b86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Embedded files with WebAssembly

[Scott Pakin]

I just started playing with WebAssembly, and I realize I don't know how to 
work with files.  For C, the Emscripten compiler apparently supports 
embedding files into a virtual file system.  Does the go command provide an 
equivalent when generating .wasm files?  Should I use Packr 
?  Something else?

Thanks,
— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: GoAWK: an AWK interpreter written in Go

[Scott Pakin]

On Friday, November 23, 2018 at 1:58:37 PM UTC-7, Ben Hoyt wrote:
>
> So my main suggestion (for spakin/awk) would be able to wrap os.Stdout in 
> a bufio.NewWriter (and be sure to call Flush before Run finishes). If the 
> user wants to pass an unbuffered version, they still can, but at least the 
> default is performant.
>
> I also added CPU profiling to the spakin/awk script, and it looks like 
> it's doing a bunch more garbage collection than GoAWK, as well as some 
> regexp stuff. I suspect NewValue() is probably quite slow as it takes an 
> interface{} and does type checking. Also, strings are converted to numbers 
> using a regex, which is probably slower than a dedicated conversion/check 
> function (see parseFloatPrefix in goawk/interp/value.go).
>
> See more optimization ideas in my post at 
> https://benhoyt.com/writings/goawk/
>

Thanks for doing the performance analysis of spakin/awk 
!  Once I find the time to work on that 
project some more, I'll certainly look into implementing some of your 
suggestions.

— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Go 2 error-handling counter-proposal: returnfrom

[Scott Pakin]

On Friday, September 14, 2018 at 12:30:46 AM UTC-6, rog wrote:
>
> What about here, where the call stack associated with g is still live?
>
>  func g() error {
>  Top:
> f := func(err error) { returnfrom Top, nil }
> c := make(chan struct{})
> go func() {
> defer close(c)
> f(nil)
> }()
> <-c
> }
>
> ?
>

Yeah, in my proposal, under Issues 
, I 
do mention that the interaction with goroutines needs to be thought through.

With respect to your example, I hope we can all agree that it would be odd 
and un-Go-like for the goroutine to cause g to return, right?  Hence, I'd 
argue that the best solution would be to generate an error at compile 
time.  "I see that the evaluation of an anonymous function is being passed 
to go.  That function calls f.  f lexically includes a returnfrom.  The 
returnfrom lexically refers to a label, Top, that's outside the anonymous 
function.  Error!"  I'm not positive the compiler can do that in all cases, 
but I'd think a conservative approach ought to work.  That is, if an 
anonymous function *might* call a function that *might* returnfrom an 
invalid location, the compiler should still issue an error message.  I 
can't imagine such conservativism causing headaches for real code, only for 
contrived examples.

If it's really not possible to make compile-time detection work, I'd say 
that the returnfrom in f should exit the goroutine but not return its 
argument from g.  This is consistent with the case of returning from a 
continuation that's no longer live.

— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 2 error-handling counter-proposal: returnfrom

[Scott Pakin]

On Thursday, September 13, 2018 at 4:00:28 PM UTC-6, Jonathan Amsterdam 
wrote:
>
> What's the meaning of this code?
>
>func main() {
>f := g()
>f()
> }
>
>func g() func() {
>Top:
>return func() { returnfrom Top,   nil}
>}
>

It means you're an evil programmer.  

My thinking is that returning from a no-longer-accessible continuation 
should simply be a no-op.  Stepping through your example, f := g() assigns 
func() 
{ returnfrom Top, nil } to f.  At this point the call stack associated with 
g() is no longer live.  f() executes, turning into returnfrom Top, nil.  
The returnfrom causes the inner function to return immediately and 
instructs g() to return nil.  But because the continuation corresponding to 
the call to g that returned the inner function no longer exists, there's no 
place to send that nil, and nothing happens.

I believe this is a simpler and more Go-like semantics than, say, Scheme's 
call/cc, which *does* execute the f := g() statement twice:

(define (main)
  (let ((f (g)))
;(printf "Calling f = ~s~n" f)
(f)))

(define (g)
  (call/cc
   (lambda (Top)
 (lambda ()
   (Top '())


(Uncomment the printf to see the double execution.  Weird, huh?)

Thanks for the challenge,
— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Go 2 error-handling counter-proposal: returnfrom

[Scott Pakin]

I recently added to the Go 2 Error Handling Feedback 
 page my 
thoughts on how to improve upon the draft design for error handling 

:

Go 2 error handling based on non-local returns 



You can read the details by clicking on that link, but the idea is to 
introduce a single new keyword, returnfrom, that a function can use to 
return from a lexically enclosing scope.  Thus, one can define an error 
handler—as an ordinary function, not a handle.  One can check any status 
type—unlike check, which is limited to error.  And one can stack error 
handlers, but this is explicit, not implicit as in handle.

Personally, I find returnfrom to be a better solution than check/handle 
while still retaining the key benefits of that approach.  See what you 
think.

— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: GoAWK: an AWK interpreter written in Go

[Scott Pakin]

On Friday, August 24, 2018 at 3:13:25 PM UTC-6, Ben Hoyt wrote:
>
> I recently wrote an AWK interpreter in Go: 
> https://github.com/benhoyt/goawk
>
> It's a pretty simple implementation: hand-rolled lexer, recursive-descent 
> parser, and tree-walk interpreter. It's pretty complete according to the 
> POSIX spec, and it passes the AWK ("one true awk") test suite as well as my 
> own unit tests.
>
> In some quick tests I ran, I/O speed is on a par or better than AWK but 
> the interpreter itself is quite slow -- about 5x slower for a lot of 
> things. I hope to add some proper benchmarks soon. I have a pretty good of 
> why and how to fix it: variable lookup and assignment is slow, and I'm 
> planning to fix by resolving more things at parse time.
>
> One thing that's a bit funky about AWK is its type handling: string values 
> can be real strings or "numeric strings" (numbers that came from user 
> input). I'm currently passing the "value" struct (see interp/value.go) 
> around by value. I still need to test if that's a good idea 
> performance-wise or not.
>
> I'd love to hear any comments, bug reports, or -- especially -- code 
> reviews.
>

Once you have some proper benchmarks, it might be fun to compare GoAWK's 
performance to that of my awk package .  The 
package implements AWK semantics in Go so a typical program is far more 
verbose than it would be in AWK but integrates tightly with Go code (e.g., 
one can use arbitrary Go code within the body of an AWK action).  GoAWK 
seems a lot easier to use when that level of integration is not needed, 
however.

I don't know how much performance difference this makes in practice, but my 
value struct (also in a value.go file) lazily converts among strings, 
floats, and ints and caches the conversions.  I don't keep track of "the" 
type of a value (your typ field), just whether I have a currently valid 
string/float/int representation.

No need to change your lexer/parser at this stage, but I've recently grown 
quite fond of PEG parsers 
.  These are a 
lot like hand-rolled, recursive-descent parsers so they're relatively easy 
to wrap your head around and reasonably powerful but require less 
code/effort than actually rolling your own.  For Go, I've used pigeon 
 for a few projects (e.g., edif2qmasm 
, for which a PEG parser is probably 
overkill).  I like pigeon, but I admit I didn't do a thorough analysis of 
all the available PEG parsers for Go before going with that one.

Nice work!

— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go could really use a while statement

[Scott Pakin]

On Wednesday, May 9, 2018 at 4:59:35 PM UTC-6, matthe...@gmail.com wrote:
>
> I’m not sure if C has been directly mentioned. I started with C so 
> iteration is just a nice shortcut to me. Assuming you’ve always had 
> collection iteration available an explanation is the for loop can make the 
> useful pattern of indexing into an array up to the length of the array 
> using an index variable.
>
> s := [5]int{0, 1, 2, 3, 4}
> // this C-style iteration prints 12345
> for i := 0; i < len(s); i++ {
> fmt.Print(s[i]+1)
> }
>
> …except that in Go one would more naturally write

for _, e := range s {
fmt.Print(e + 1)
}

— Scott 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Flag package issue when nonflag argument string begins with a minus sign

[Scott Pakin]

On Wednesday, January 24, 2018 at 11:00:37 AM UTC-7, erisa wrote:
>
> I have a CLI program that uses the flag package and has one flag and takes 
> a string as its only nonflag argument.  The string can be a complex 
> expression, but it is possible that the first character of the string is a 
> minus sign.
> This parses correctly:
>
> powerseries -nterms=10 "x ^ 10"
>
> But this does not:
>
> powerseries -nterms=10 "-x ^ 10"
>
> It yields the error "flag provided but not defined: -x ^ 10".
>
> Is there a workaround for this problem?
>

Yes:

powerseries -nterms=10 -- "-x ^ 10"


The "--" means "end of flag arguments."

— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Doing "C-like" things in Go

[Scott Pakin]

On Monday, September 11, 2017 at 7:25:54 PM UTC-6, Michael Jones wrote:
>
> int(boolvalue) could mean 0 for false and 1 otherwise
> bool(intvalue) could mean false for 0 an true otherwise
>
> quite a useful notion
>

 Yeah, too bad that was shot down years ago (cf. proposal: support 
int(bool) conversions in Go.1.5 

).

— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Explain the meaning of iota

[Scott Pakin]

On Friday, June 30, 2017 at 9:28:50 PM UTC-6, Manohar Reddy wrote:
>
> `iota` is golnag's enum. I've seen this code in Wikipedia. But I did not 
> understand it. Can someone please explain this code?
>

In the first line of the const block, iota is 0, and this is assigned to "_" 
(i.e., discarded).

In the second line of the const block, iota is 1, so KB (of type ByteSize) 
is defined as 1 << (10 * 1), which is 1024.

The third line of the const block inherits the previous line's pattern so 
it's effectively KB ByteSize = 1 << (10 * iota). Because iota is now 2, MB 
is defined as 1 << (10 * 2), which is 1048576.

Likewise, in the fourth line of the const block, iota is 3 so GB is defined 
as 1 << (10 * 3), which is 1073741824.

— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] [ANN] New package for interning strings

[Scott Pakin]

I just released a package called intern  
for speeding up string comparisons.  Install it in the usual manner:

go get github.com/spakin/intern


The package defines two interned-string types, Eq and LGE, and functions to 
allocate them.  Internally, both are represented as integers so comparisons 
run in constant time, regardless of the length of the corresponding string. 
 Hence, programs that frequently compare strings, especially strings with 
large, common prefixes, stand to gain the most in performance.

Both Eq and LGE define a String method that recovers the original string. 
 Hence, in some cases (e.g., fmt.Printf ) 
they can serve as a drop-in replacement for strings.

The difference between the two types is the set of comparisons they 
support.  For strings s1 and s2 and corresponding Eqs e1 and e2,

   - if s1 == s2 then e1 == e2, and
   - If s1 != s2 then e1 != e2.

LGEs, which I've never encountered in a string-interning package for *any* 
language, support a richer set of comparisons.  For strings s1 and s2 and 
corresponding LGEs l1 and l2,

   - if s1 == s2 then l1 == l2,
   - if s1 != s2 then l1 != l2,
   - if s1 < s2 then l1 < l2,
   - if s1 > s2 then l1 > l2,
   - and likewise for <= and >=.

However, LGEs are slower to allocate than Eqs, and allocation can fail. 
 See the package documentation  and 
examples for information on how to recover from that situation.

Enjoy,
— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Reading stdlib for education about go?

[Scott Pakin]

On Friday, May 12, 2017 at 4:39:54 AM UTC-6, Steve Mynott wrote:
>
> What parts of the go stdlib are particularly useful for self education 
> in general go? 
>

It's been a while since I looked, but I recall image/png 
 (or any of its file-format siblings) 
and its dependencies, image  and image/color 
, being helpfui for understanding when 
to use interfaces and when to use concrete types when implementing a set of 
interrelated abstractions (in this case, various image formats that can be 
encoded, decoded, and manipulated with most of the implementation details 
hidden).

― Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: File path extractor Regexp

[Scott Pakin]

On Thursday, March 2, 2017 at 6:50:16 AM UTC-7, Nyah Check wrote:
>
> I am currently developing an application that identifies strings looking 
> like a file path and collects them and returns the array of strings. Over 
> the past week, I developed a regex to identify file paths  to this: 
> "(?:/[A-Z\\d.][A-Z\\d\\-.]{0,61})+". That does not seem to work. Can 
> anyone give me an alternative? 
>

Untested: (/[^/\s[:^graph:]]{1,61})+

— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: bit twiddling API survey

[Scott Pakin]

On Monday, January 9, 2017 at 6:07:19 PM UTC-7, ma...@influxdb.com wrote:
>
> I haven't personally experienced a need for a bit twiddling API, but if 
> you're looking for other interesting operations, you might want to check 
> out the awesome-bits curated list of bitwise operations [1].
>
> [1] https://github.com/keonkim/awesome-bits
>

Sean Eron Anderson's Bit Twiddling Hacks 
 is another good 
reference source.

— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: In case you missed it: language benchmarks for Go 1.7, and language adoption

[Scott Pakin]

On Monday, August 29, 2016 at 5:51:42 PM UTC-6, Eric Johnson wrote:
>
> Not that I think these account for much, but sort of fun to point at:
>
> https://benchmarksgame.alioth.debian.org/u64q/go.html
> (Short summary - now with Go 1.7, Go is faster for most benchmarks.)
>

Go 1.7 is faster than C on the mandelbrot test and faster than C++ also on 
reverse-complement?  How did *that* happen?

— Scott

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.