[go-nuts] Code Conversion

[Mandolyte]

Does anyone have any experience 
with https://www.codeconvert.ai/typescript-to-golang-converter (or any of 
their other conversion products)?

I'm assessing how big a job it would be to support Djot 
(https://github.com/jgm/djot) with Go. It currently has both Lua and a 
Javascript/Typescript implementations.

Perhaps there other approaches? Any advice welcomed!

As I think about, here are other approaches I might consider:

   - Convert to WASM (and use the new Go WASI support)
   - Use Go Lua interpreter (almost sure there is one (or more))

Thanks!

-- 
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/4da3b182-5b35-4b53-96e6-1add636a34e9n%40googlegroups.com.

Re: [go-nuts] File size of Google docs when mounted

[Mandolyte]

For the sake of posterity... here is what Bard says.

*Prompt*: In golang, develop code to find the size of a google doc

*Response*:

To find the size of a Google Doc in Golang, you can use the following steps:

   1. Import the necessary packages: 

import ( "context" "fmt" "io/ioutil" "net/http" 
"github.com/google/go-auth/oauth2" 
"github.com/googleapis/google-api-go/docs/v1" ) 

   1. Create a new OAuth2 client and obtain an access token: 

ctx := context.Background() config := oauth2.Config{ ClientID: 
"YOUR_CLIENT_ID", ClientSecret: "YOUR_CLIENT_SECRET", Scopes: 
[]string{"https://www.googleapis.com/auth/drive.readonly"}, RedirectURL: 
"http://localhost:8080/oauth2callback;, } token, err := 
config.Exchange(ctx, "YOUR_AUTHORIZATION_CODE") if err != nil { 
log.Fatalf("Unable to exchange code: %v", err) } 

   1. Create a new Google Docs client: 

client := docs.NewService(http.Client{ Transport: { 
Source: token, }, }) 

   1. Get the size of the Google Doc: 

docID := "YOUR_DOCUMENT_ID" req, err := client.Documents.Get(docID).Do(ctx) 
if err != nil { log.Fatalf("Unable to get document: %v", err) } size := 
req.ContentLength 

   1. Print the size of the Google Doc: 

fmt.Printf("The size of the Google Doc is %d bytes\n", size) 

Here is a complete example of a Golang program to find the size of a Google 
Doc:
package main import ( "context" "fmt" "io/ioutil" "net/http" 
"github.com/google/go-auth/oauth2" 
"github.com/googleapis/google-api-go/docs/v1" ) func main() { ctx := 
context.Background() config := oauth2.Config{ ClientID: "YOUR_CLIENT_ID", 
ClientSecret: "YOUR_CLIENT_SECRET", Scopes: 
[]string{"https://www.googleapis.com/auth/drive.readonly"}, RedirectURL: 
"http://localhost:8080/oauth2callback;, } token, err := 
config.Exchange(ctx, "YOUR_AUTHORIZATION_CODE") if err != nil { 
log.Fatalf("Unable to exchange code: %v", err) } client := 
docs.NewService(http.Client{ Transport: { Source: token, 
}, }) docID := "YOUR_DOCUMENT_ID" req, err := 
client.Documents.Get(docID).Do(ctx) if err != nil { log.Fatalf("Unable to 
get document: %v", err) } size := req.ContentLength fmt.Printf("The size of 
the Google Doc is %d bytes\n", size) } 

To use this code, you will need to replace the following values:

   - YOUR_CLIENT_ID: Your Google Cloud Platform client ID. 
   - YOUR_CLIENT_SECRET: Your Google Cloud Platform client secret. 
   - YOUR_AUTHORIZATION_CODE: An authorization code that you can obtain by 
   following the OAuth2 flow. 
   - YOUR_DOCUMENT_ID: The ID of the Google Doc that you want to find the 
   size of. 

Once you have replaced these values, you can compile and run the code. The 
program will print the size of the Google Doc to the console.
On Thursday, October 5, 2023 at 10:12:25 PM UTC-4 Mandolyte wrote:

> Yeah, I need someone who knows something about how gdrive does things. 
> Thanks for the help!
>
> On Thursday, October 5, 2023 at 7:43:08 PM UTC-4 Kurtis Rader wrote:
>
>> Did you notice the `ls` command reports the file size is 170? The same as 
>> your program? Also, `ls` does not indicate the file is a symlink so the 
>> fact that ioutil.ReadDir presumably behaves the same as os.ReadDir (i.e., 
>> both use os.Lstat()) that isn't an issue. So for whatever reason the Google 
>> Drive FS is either not reporting the actual size of the file or the file is 
>> really just 170 bytes in length.
>>
>> On Thu, Oct 5, 2023 at 4:31 PM Mandolyte  wrote:
>>
>>> Here is what I see:
>>> $ ls -l Household\ Cleaning.gdoc 
>>> -rw-r- 1 cecil chronos-access 170 Apr 22 15:30 'Household 
>>> Cleaning.gdoc'
>>> $ 
>>>
>>> I'll update the code to remove the deprecated and see if that is any 
>>> different.
>>> On Thursday, October 5, 2023 at 6:06:50 PM UTC-4 Kurtis Rader wrote:
>>>
>>>> Note that ioutil.ReadDir() has been deprecated since Go 1.16. Which is 
>>>> a very long time. Its documentation is ambiguous but given the behavior 
>>>> you're reporting I would guess it is using the equivalent of os.Lstat() 
>>>> and 
>>>> the "files" you're dealing with are symlinks. Note that os.ReadDir() 
>>>> (which 
>>>> replaced ioutil.ReadDir) explicitly states that is what it does:
>>>>
>>>> Readdir reads the contents of the directory associated with file and 
>>>> returns a slice of up to n FileInfo values, as would be returned by Lstat, 
>>>> in directory order. Subsequent calls on the same file will yield further 
>

Re: [go-nuts] File size of Google docs when mounted

[Mandolyte]

Yeah, I need someone who knows something about how gdrive does things. 
Thanks for the help!

On Thursday, October 5, 2023 at 7:43:08 PM UTC-4 Kurtis Rader wrote:

> Did you notice the `ls` command reports the file size is 170? The same as 
> your program? Also, `ls` does not indicate the file is a symlink so the 
> fact that ioutil.ReadDir presumably behaves the same as os.ReadDir (i.e., 
> both use os.Lstat()) that isn't an issue. So for whatever reason the Google 
> Drive FS is either not reporting the actual size of the file or the file is 
> really just 170 bytes in length.
>
> On Thu, Oct 5, 2023 at 4:31 PM Mandolyte  wrote:
>
>> Here is what I see:
>> $ ls -l Household\ Cleaning.gdoc 
>> -rw-r- 1 cecil chronos-access 170 Apr 22 15:30 'Household 
>> Cleaning.gdoc'
>> $ 
>>
>> I'll update the code to remove the deprecated and see if that is any 
>> different.
>> On Thursday, October 5, 2023 at 6:06:50 PM UTC-4 Kurtis Rader wrote:
>>
>>> Note that ioutil.ReadDir() has been deprecated since Go 1.16. Which is a 
>>> very long time. Its documentation is ambiguous but given the behavior 
>>> you're reporting I would guess it is using the equivalent of os.Lstat() and 
>>> the "files" you're dealing with are symlinks. Note that os.ReadDir() (which 
>>> replaced ioutil.ReadDir) explicitly states that is what it does:
>>>
>>> Readdir reads the contents of the directory associated with file and 
>>> returns a slice of up to n FileInfo values, as would be returned by Lstat, 
>>> in directory order. Subsequent calls on the same file will yield further 
>>> FileInfos.
>>>
>>> On Thu, Oct 5, 2023 at 1:35 PM Mandolyte  wrote:
>>>
>>>> Thanks for responding! The entire program may be found here: 
>>>> https://go.dev/play/p/4kLaeWeQG0Z
>>>>
>>>> The size comes from os.FileInfo, which is:
>>>>
>>>> type FileInfo interface {
>>>> Name() string <https://pkg.go.dev/builtin#string> // base name of the 
>>>> file Size() int64 <https://pkg.go.dev/builtin#int64> // length in 
>>>> bytes for regular files; system-dependent for others Mode() FileMode 
>>>> <https://pkg.go.dev/io/fs#FileMode> // file mode bits ModTime() time 
>>>> <https://pkg.go.dev/time>.Time <https://pkg.go.dev/time#Time> // 
>>>> modification time IsDir() bool <https://pkg.go.dev/builtin#bool> // 
>>>> abbreviation for Mode().IsDir() Sys() any 
>>>> <https://pkg.go.dev/builtin#any> // underlying data source (can return 
>>>> nil) }
>>>>
>>>> These are collected around line 112 and following.
>>>> On Thursday, October 5, 2023 at 1:12:48 PM UTC-4 Kurtis Rader wrote:
>>>>
>>>>> It would help if you showed us the relevant code. My first guess is 
>>>>> those files are symlinks. Or perhaps this is simply what Google Drive 
>>>>> reports when a file is stat()'d. What does `ls -l` show?
>>>>>
>>>>> On Thu, Oct 5, 2023 at 8:31 AM Mandolyte  wrote:
>>>>>
>>>>>> I have a program that given a starting folder will walk the directory 
>>>>>> structure and report file sizes and other things.
>>>>>>
>>>>>> I recently tried to run this code on a mounted Google Drive on 
>>>>>> ChromeOS Linux. All the google docs report a size 170 bytes. Snippet:
>>>>>>
>>>>>> [image: Screenshot 2023-10-05 11.29.44 AM.png]
>>>>>>
>>>>>> Any pointers appreciated!
>>>>>>
>>>>>> -- 
>>>>>> 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...@googlegroups.com.
>>>>>> To view this discussion on the web visit 
>>>>>> https://groups.google.com/d/msgid/golang-nuts/8faf6106-2fdd-49e3-a193-e8f41605fbffn%40googlegroups.com
>>>>>>  
>>>>>> <https://groups.google.com/d/msgid/golang-nuts/8faf6106-2fdd-49e3-a193-e8f41605fbffn%40googlegroups.com?utm_medium=email_source=footer>
>>>>>> .
>>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Kurtis Rader
>>>>> Caretaker of the exceptional canines Junior and Hank
>>>>&

Re: [go-nuts] File size of Google docs when mounted

[Mandolyte]

Here is what I see:
$ ls -l Household\ Cleaning.gdoc 
-rw-r- 1 cecil chronos-access 170 Apr 22 15:30 'Household Cleaning.gdoc'
$ 

I'll update the code to remove the deprecated and see if that is any 
different.
On Thursday, October 5, 2023 at 6:06:50 PM UTC-4 Kurtis Rader wrote:

> Note that ioutil.ReadDir() has been deprecated since Go 1.16. Which is a 
> very long time. Its documentation is ambiguous but given the behavior 
> you're reporting I would guess it is using the equivalent of os.Lstat() and 
> the "files" you're dealing with are symlinks. Note that os.ReadDir() (which 
> replaced ioutil.ReadDir) explicitly states that is what it does:
>
> Readdir reads the contents of the directory associated with file and 
> returns a slice of up to n FileInfo values, as would be returned by Lstat, 
> in directory order. Subsequent calls on the same file will yield further 
> FileInfos.
>
> On Thu, Oct 5, 2023 at 1:35 PM Mandolyte  wrote:
>
>> Thanks for responding! The entire program may be found here: 
>> https://go.dev/play/p/4kLaeWeQG0Z
>>
>> The size comes from os.FileInfo, which is:
>>
>> type FileInfo interface {
>> Name() string <https://pkg.go.dev/builtin#string> // base name of the 
>> file Size() int64 <https://pkg.go.dev/builtin#int64> // length in bytes 
>> for regular files; system-dependent for others Mode() FileMode 
>> <https://pkg.go.dev/io/fs#FileMode> // file mode bits ModTime() time 
>> <https://pkg.go.dev/time>.Time <https://pkg.go.dev/time#Time> // 
>> modification time IsDir() bool <https://pkg.go.dev/builtin#bool> // 
>> abbreviation for Mode().IsDir() Sys() any 
>> <https://pkg.go.dev/builtin#any> // underlying data source (can return 
>> nil) }
>>
>> These are collected around line 112 and following.
>> On Thursday, October 5, 2023 at 1:12:48 PM UTC-4 Kurtis Rader wrote:
>>
>>> It would help if you showed us the relevant code. My first guess is 
>>> those files are symlinks. Or perhaps this is simply what Google Drive 
>>> reports when a file is stat()'d. What does `ls -l` show?
>>>
>>> On Thu, Oct 5, 2023 at 8:31 AM Mandolyte  wrote:
>>>
>>>> I have a program that given a starting folder will walk the directory 
>>>> structure and report file sizes and other things.
>>>>
>>>> I recently tried to run this code on a mounted Google Drive on ChromeOS 
>>>> Linux. All the google docs report a size 170 bytes. Snippet:
>>>>
>>>> [image: Screenshot 2023-10-05 11.29.44 AM.png]
>>>>
>>>> Any pointers appreciated!
>>>>
>>>> -- 
>>>> 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...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/golang-nuts/8faf6106-2fdd-49e3-a193-e8f41605fbffn%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/golang-nuts/8faf6106-2fdd-49e3-a193-e8f41605fbffn%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>
>>>
>>> -- 
>>> Kurtis Rader
>>> Caretaker of the exceptional canines Junior and Hank
>>>
>> -- 
>> 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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/f00d389d-e55a-4afe-8754-c5acd063c320n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/f00d389d-e55a-4afe-8754-c5acd063c320n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/69891205-4545-4242-86b5-55485db21276n%40googlegroups.com.

Re: [go-nuts] File size of Google docs when mounted

[Mandolyte]

Thanks for responding! The entire program may be found 
here: https://go.dev/play/p/4kLaeWeQG0Z

The size comes from os.FileInfo, which is:

type FileInfo interface {
Name() string <https://pkg.go.dev/builtin#string> // base name of the file 
Size() 
int64 <https://pkg.go.dev/builtin#int64> // length in bytes for regular 
files; system-dependent for others Mode() FileMode 
<https://pkg.go.dev/io/fs#FileMode> // file mode bits ModTime() time 
<https://pkg.go.dev/time>.Time <https://pkg.go.dev/time#Time> // 
modification time IsDir() bool <https://pkg.go.dev/builtin#bool> // 
abbreviation for Mode().IsDir() Sys() any <https://pkg.go.dev/builtin#any> // 
underlying data source (can return nil) }

These are collected around line 112 and following.
On Thursday, October 5, 2023 at 1:12:48 PM UTC-4 Kurtis Rader wrote:

> It would help if you showed us the relevant code. My first guess is those 
> files are symlinks. Or perhaps this is simply what Google Drive reports 
> when a file is stat()'d. What does `ls -l` show?
>
> On Thu, Oct 5, 2023 at 8:31 AM Mandolyte  wrote:
>
>> I have a program that given a starting folder will walk the directory 
>> structure and report file sizes and other things.
>>
>> I recently tried to run this code on a mounted Google Drive on ChromeOS 
>> Linux. All the google docs report a size 170 bytes. Snippet:
>>
>> [image: Screenshot 2023-10-05 11.29.44 AM.png]
>>
>> Any pointers appreciated!
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/8faf6106-2fdd-49e3-a193-e8f41605fbffn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/8faf6106-2fdd-49e3-a193-e8f41605fbffn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/f00d389d-e55a-4afe-8754-c5acd063c320n%40googlegroups.com.

[go-nuts] File size of Google docs when mounted

[Mandolyte]

I have a program that given a starting folder will walk the directory 
structure and report file sizes and other things.

I recently tried to run this code on a mounted Google Drive on ChromeOS 
Linux. All the google docs report a size 170 bytes. Snippet:

[image: Screenshot 2023-10-05 11.29.44 AM.png]

Any pointers appreciated!

-- 
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/8faf6106-2fdd-49e3-a193-e8f41605fbffn%40googlegroups.com.

[go-nuts] Re: How to convert an svg to a png (or gif) image?

[Mandolyte]

and https://pkg.go.dev/github.com/canhlinh/svg2png

On Friday, August 4, 2023 at 4:48:26 AM UTC-4 Mark wrote:

> Thanks!
>
> On Friday, August 4, 2023 at 8:46:18 AM UTC+1 Tamás Gulácsi wrote:
>
>> https://pkg.go.dev/github.com/goki/gi/svg
>>
>> Mark a következőt írta (2023. augusztus 3., csütörtök, 13:18:48 UTC+2):
>>
>>> I know this has been asked before, just wondered if there were any 
>>> pure-Go solutions?
>>>
>>

-- 
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/eac3ed54-4972-4675-a515-d6741865b2c3n%40googlegroups.com.

[go-nuts] Using Go/WASM for web app functions

[Mandolyte]

In a few months I will begin working on a component that can be used by 
several of our web apps. Since I have time I wanted to experiment with 
writing this in Go/WASM. 


The Go code will be a set of functions that take a string and some options 
(probably in JSON format) and return a string (same string possibly with 
some fixes) and an array of warnings, errors, etc. (probably in a 2D 
array). 


These functions will not need to access the DOM or do any UI/X. It is 
possible that a web worker will be used to run them (they could be long 
running).

Here is what I think needs to be done:

   - 
   
   Write the Go code
   - 
   
   Compile to WASM
   - 
   
   Publish to NPM
   

At that point, the web apps can import my functions and use them, hopefully 
as normal JavaScript modules.

Any feedback or links to examples where this has been done would be 
appreciated. I have come across Rust examples like this, but not Go (at 
least I didn’t recognize any).

Thanks!

-- 
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/0044c8c9-d3a6-4068-9404-eb2ad5c4c404n%40googlegroups.com.

Re: [go-nuts] Generics: Whats the best way around limitation that methods can't be parameterized

[Mandolyte]

Or perhaps a hybrid, where the methods call generic functions...

On Thursday, January 20, 2022 at 7:23:37 PM UTC-5 Ian Lance Taylor wrote:

> On Thu, Jan 20, 2022 at 3:30 AM Travis Keep  wrote:
> >
> > I am working on a Pipeline[T, U any] type which receives any number of T 
> values and in turn emits U values. Pipelines are used to read from 
> databases.
> >
> > For instance, this code fetches the ages of 5 people under 50.
> >
> > int[] ages
> > PeopleOrderedByName(Start[Person]().
> > Map(func(p Person) int { return p.Age }).
> > Filter(func(age int) bool { return age < 50 }).
> > Slice(0, 5).
> > AppendTo())
> >
> > // Output: {49, 19, 25, 34, 42}
> > fmt.Println(ages)
> >
> > Some notes about this code:
> >
> > 1. Start[Person]() returns a Pipeline[Person, Person] that emits each 
> Person value it receives.
> > 2. the Map method on Pipeline is parameterized. What Map returns depends 
> on the return value of the mapper function passed in. In the example above, 
> Map() returns a Pipeline[Person, int]
> > 3. AppendTo() returns a Consumer[Person] which takes Person values 
> without emitting anything. As a side effect, this Consumer[Person] appends 
> the ages of people under 50 to the ages slice.
> > 4. Even if there are millions of people in the database, this code will 
> read just enough people to get 5 ages under 50.
> > 5. This code won't work in 1.18 because methods in GO on a parameterized 
> type like Pipeline cannot be further parameterized, but in this API, the 
> Map() method has to be parameterized.
> >
> > To get around this limitation, I revised my API to look like this:
> >
> > int[] ages
> > PeopleOrderedByName(
> > SendTo[Person, int](
> > Start().
> > Map(func(person interface{}) interface{} { return person.(Person).Age }).
> > Filter(func(age interface{}) bool { return age.(int) < 50 }).
> > Slice(0, 5),
> > AppendTo())
> >
> > // Output: {49, 19, 25, 34, 42}
> > fmt.Println(ages)
> >
> > Notes about this API:
> >
> > 1. Pipeline is no longer a parameterized type. Pipeline instances 
> receive interface{} values and emit interface{} values.
> > 2. AppendTo() returns a Consumer[int] that appends all the values 
> it receives to the ages slice.
> > 3. SendTo[Person, int]() returns a Consumer[Person] that applies a 
> pipeline to the Person values it receives and then sends the emitted values 
> to the Consumer[int] passed as a second value.
> > 4. This API suffers all the disadvantages that generics aims to solve. 
> The pipeline code is clunkier because values have to be constantly 
> converted from interface{}, Problems with type mismatches become runtime 
> errors instead of compile time errors, storing a Person value in an 
> interface results in an extra memory allocation etc.
> >
> > Is there a more elegant way around the limitation that methods on 
> parameteried types can't be parameterized?
>
>
> I don't know about "more elegant" but I would suggest not trying to
> use a fluent API. Use a function based API instead. Maybe it would
> look like
>
> p := pipelinePeopleOrderedByName(Start[Person]()
> p = pipeline.Map(p, func(p Person) int { return p.Age })
> p = pipeline.Filter(p, func(age int) bool { return age < 50 })
> p = pipeline.Slice(p, 0, 5)
> ages = append(ages, pipeline.Results(p))
>
> (Of course I've omitted the error handling, but your example did as well.)
>
> Ian
>

-- 
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/163d0bd5-a50f-45d0-96bb-1129685a5037n%40googlegroups.com.

Re: [go-nuts] [ANN] CGo-free sqlite database/sql driver 1.4.0 for linux/amd64 released

[Mandolyte]

A couple of questions:

   - What is the state of Windows/MacOS?
   - How about Windows Subsystem for Linux?

Thanks!
On Wednesday, August 26, 2020 at 6:17:58 PM UTC-4 kortschak wrote:

> On Wed, 2020-08-26 at 23:50 +0200, Jan Mercl wrote:
> > From the change log (
> > https://godoc.org/modernc.org/sqlite#hdr-Changelog)
> > 
> > 2020-08-26 v1.4.0:
> > 
> > First stable release for linux/amd64. The database/sql driver and its
> > tests are CGo free. Tests of the translated sqlite3.c library still
> > require CGo.
> > 
> > $ make full
> > 
> > ...
> > 
> > SQLite 2020-08-14 13:23:32
> > fca8dc8b578f215a969cd899336378966156154710873e68b3d9ac5881b0ff3f
> > 0 errors out of 928271 tests on 3900x Linux 64-bit little-endian
> > WARNING: Multi-threaded tests skipped: Linked against a non-
> > threadsafe Tcl build
> > All memory allocations freed - no leaks
> > Maximum memory usage: 9156360 bytes
> > Current memory usage: 0 bytes
> > Number of malloc() : -1 calls
> > --- PASS: TestTclTest (1785.04s)
> > PASS
> > ok modernc.org/sqlite 1785.041s
> > $
> > 
>
> This is just what I have been looking for for a little toy I'm writing.
>
>
>

-- 
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/033fe992-bcce-4870-bf52-4b7e54ca1caen%40googlegroups.com.

Re: [go-nuts] Re: Generics and parentheses

[Mandolyte]

Since readability is impacted by consequitive lists, you could factor it out... 

with ( type list )
func ( arg list ) etc...

-- 
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/e06fc6ac-d4fe-433c-aacc-7e94b9352e77o%40googlegroups.com.

[go-nuts] Re: pure-go implementation of sqlite

[Mandolyte]

SQLite3 support is the stated goal of https://github.com/elliotchance/c2go

Also, I believe I tested this one a long time ago... but have lost track of 
it after they moved away from Github:
https://github.com/cznic/sqlite



On Monday, June 15, 2020 at 12:57:54 PM UTC-4, Douglas Manley wrote:
>
> No, unfortunately this just replaces the need for gcc for SQLite3 with the 
> need for gcc for Sqinn.  My goal is to have a SQL database for use in Go 
> that is 100% pure Go with zero outside dependencies.  My primary use case 
> is for unit-testing large applications that rely on SQL databases such that 
> no one on the project has to do anything other than install Go to build and 
> test them.
>
> On Monday, June 15, 2020 at 12:31:07 PM UTC-4 cvilsmeier wrote:
>
>> Maybe Sqinn-Go can help you:
>> https://github.com/cvilsmeier/sqinn-go
>> (I'm the author of it)
>>
>>

-- 
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/2c533170-33b5-4eb5-9f58-25c88f34710fo%40googlegroups.com.

[go-nuts] Re: go2go (generics) and function binding

[Mandolyte]

Some info here on how to play with the generics:
https://blog.tempus-ex.com/generics-in-go-how-they-work-and-how-to-play-with-them/

-- 
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/13613031-90de-40a6-8df6-872865dbf803%40googlegroups.com.

[go-nuts] Re: Is it possible to segment CMD window on Windows and segment Terminal window on Linux with golang?

[Mandolyte]

Might review how the micro editor handles it... as an editor functioning in 
a terminal window and cross platform, it is quite stellar.
https://pkg.go.dev/mod/github.com/zyedidia/micro@v1.4.1

On Friday, April 10, 2020 at 6:49:12 AM UTC-4, Jason E. Aten wrote:
>
> If you insist on terminal (which as I pointed out, is a mistake; I have 
> made it and learned better), then
>
> https://github.com/rivo/tview
>
> is probably the better choice versus termui.
>

-- 
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/e7c3fa09-6990-4dbe-b7b0-ca3da9b87130%40googlegroups.com.

[go-nuts] Re: pure-go implementation of sqlite

[Mandolyte]

I have tested this one: https://godoc.org/modernc.org/sqlite -- but not 
extensively and it states it should not be used for production. (my testing 
was on the "archived" github version)

And this is the goal of https://github.com/elliotchance/c2go -- but can't 
tell if it is active or whether it actually has gotten to sqlite at all.

On Friday, October 18, 2019 at 11:08:20 AM UTC-4, 
doug@extreme-scale.com wrote:
>
> As of right now, all I've been able to find is this (incomplete) read-only 
> implementation: https://github.com/alicebob/sqlittle
>
> On Tuesday, July 1, 2014 at 8:27:34 AM UTC-4, Sebastien Binet wrote:
>>
>> hi there, 
>>
>> is there (or is somebody working on) a pure-go implementation of sqlite ? 
>> or at least a subset of it, to be able to read sqlite files ? 
>>
>> -s 
>>
>> PS: I know about the (by now) canonical implementations 
>> (mattn/go-sqlite and others) but a completely go-based solution would 
>> facilitate deployment and development across devs machines... 
>>
>

-- 
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/90bac31a-1af8-4293-9102-9e8ac2de39ae%40googlegroups.com.

Re: [go-nuts] Quick question about the new Contracts Draft Proposal

[Mandolyte]

In this code snippet:

> func Map(type S, Element)(s S, f func(Element) Element) S {
>   r := make(S, len(s))
>   for i, v := range s {
>   r[i] = f(s)
>   }
>   return r}
>
> Shouldn't the line in the loop be: r[i] = f(v)
On Monday, July 29, 2019 at 2:17:22 PM UTC-4, Ian Lance Taylor wrote:
>
> On Sun, Jul 28, 2019 at 1:15 PM Jon Bodner  > wrote: 
> > 
> > I did a first read through the proposal and it looks very good. I had 
> one question: when giving the example of how to implement Sorting using 
> orderedSlice, the type parameter is declared to be comparable. Should that 
> be contracts.Ordered? 
>
> Yes, thanks.  Will update. 
>
> Ian 
>

-- 
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/87f10070-394b-4500-a8d3-567562e12d5d%40googlegroups.com.

[go-nuts] Quick question about the new Contracts Draft Proposal

[Mandolyte]

I missed this. Do you have a link to the proposal?

-- 
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/693ac121-0e94-4448-af6d-044e3c7c22df%40googlegroups.com.

[go-nuts] Re: Go+ replacement

[Mandolyte]

I think MeWe could do the job in a functional sense - but there is no 
reason for Go folks to go there in mass. I find that Reddit has most of the 
same links to info that G+ did... so I'm ok with it. I have accounts on 
both MeWe and Reddit already for other things... so yeah...

On Sunday, April 21, 2019 at 9:13:22 PM UTC-4, icod...@gmail.com wrote:
>
> I don't know about you but for me, even if there wasn't so much going on, 
> Google+ and the Go+ community was a source of info.
>
> Reddit is reddit, this whatever it is, is what it is, mewe can't 
> replace G+.
> Facebook just isn't the crowd.
> Xing and the like just aren't made to handle the task of staying informed 
> and people presenting their work.
>
> An essential source of information has disappeared.
> What is there to replace it?
>
> People would post links to youtube videos there, some were quite 
> interesting and some were fresh from the horses mouth about whatever 
> conferences or happenings.
> It's all gone now.
>
> Nuts is more of a "help I have a problem" thing.
>
> I know, Google+ had its own issues, the biggest was them forcing changes 
> onto their users no one wanted.
> As a result most people stopped using it and in the end it disappeared.
>
> G+ did fill a nieche, that of the enterpreteur who also wanted to be 
> entertained and catch news, stay up to date.
>
> I know this post is kind of pointless, since it won't change what is.
> But maybe something exists that I'm unaware of
>

-- 
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] Generics of Kith and Kin

[Mandolyte]

I don't believe anyone has mentioned how a muon does generics... muon claims to 
be inspired by Go and some others; and indeed it feels familiar. At any rate, 
just for information and interest:
https://github.com/nickmqb/muon/blob/master/docs/muon_by_example.md#generic-structs
 

-- 
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: WebP encoder

[Mandolyte]

You might consider one of the projects that "transpile" C to Go. Might give 
you a jump start. For reference, here are two of them:
https://godoc.org/modernc.org/ccgo/v2
https://godoc.org/github.com/elliotchance/c2go/transpiler

On Sunday, December 30, 2018 at 12:08:21 AM UTC-5, Jeffrey wrote:
>
> since the libwebp has released the version 1.0.0, so it's time to port it 
> to pure golang
>

-- 
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: Announcing a Fyne GUI toolkit

[Mandolyte]

Hey, the thread isn't that old... but have a question since you are in the 
thick of GUI things: what do you think of Vulkan?

On Sunday, December 30, 2018 at 5:19:26 PM UTC-5, Andrew Williams wrote:
>
> Hi,
>
> For anyone still interested in this project but held back by the EFL build 
> or runtime dependency then I have good news:
> * Our new default driver does not rely on additional libraries * :)
>
> We have moved to an OpenGL driver - using go-gl and glfw so all you need 
> is the system libraries - and nothing for the app users to install.
> There are a couple of performance issues that we will be working on but it 
> is currently capable of running all the apps that were written with the 
> previous driver.
>
> I hope this is helpful to some folk - apologies for reviving the old 
> thread.
> Andrew
>

-- 
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 language sensitive editor?

[Mandolyte]

Hmmm, couldn't we follow directions to build from zyedidia, substituting 
your repo as needed? If so, have you documented anywhere how to use your 
extensions? I didn't notice any mods to the README.

Cheers!

On Wednesday, November 21, 2018 at 4:57:05 PM UTC-5, Serge Voilokov wrote:
>
> I am using micro editor: https://github.com/zyedidia/micro . It is 
> terminal-based, supports mouse, uses ctrl+zxcv and shift+arrows for text 
> manipulation, has a multi cursor feature, syntax highlighting.
> Written in golang. Easy to configure and change.
> I am using my fork (https://github.com/serge-v/micro) with added features 
> for golang development: go to decls, go imports, go install, go complete, 
> etc.
>
>

-- 
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: Distributed MapReduce in Go, is it possible?

[Mandolyte]

see 
https://github.com/chrislusf/glow
and 
https://github.com/chrislusf/gleam

On Thursday, November 22, 2018 at 3:32:51 PM UTC-5, yahiah...@gmail.com 
wrote:
>
> Hi how are you can you help me I need distributed mapreduce  code for 
> golan 
> Thank you  

-- 
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] Code generated by generics draft

[Mandolyte]

Sorry for the ambiguity. As I understand it, the "fo" compiler simply 
rewrites the generic function/method using the supplied type parameters and 
then tries to compile it. It would be an interesting exercise to try the 
Graph example, but as it is, I'm not certain how it would handle it, or if 
it can.

On Thursday, November 1, 2018 at 4:04:42 PM UTC-4, Jamie Clarkson wrote:
>
>
>
> On Thursday, November 1, 2018 at 6:19:58 PM UTC, Mandolyte wrote:
>>
>> Ah, I see. the albrow/fo package is the equivalent of just pasting the 
>> entire function into the contract.
>>
>>
> Could you expand on this a little, I'm not sure I follow?  Would it handle 
> the Graph contract?
>

-- 
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] Code generated by generics draft

[Mandolyte]

Ah, I see. the albrow/fo package is the equivalent of just pasting the 
entire function into the contract.

I agree, I had mixed feelings about contracts too at first. But I came to 
appreciate, in descending order:

   - It would be good documentation in godoc
   - It enables much better error messages (a problem with albrow/fo and is 
   also stated in the proposal)
   - Robust enough to handle the "edge" cases (pun intended)

I have seen some proposals that look interesting on operator overloading, 
but I could live without them. There are other ways to handle the cases 
where they would be nice to have. A good godoc goes a long way!

Cheers.

On Thursday, November 1, 2018 at 10:04:08 AM UTC-4, Jamie Clarkson wrote:
>
> Thanks, that looks like a cool project - however I'd disagree that not 
> using contracts is relevant to the question.  
>
> My interest was mainly in what would need to be implicitly generated by 
> the compiler in order to support contracts (such as the mutual recursive 
> types above), not specifically the generated code.   In fact it would be 
> cool to see if the contract mechanism could be implemented on top of Fo 
> since that already provides the parametrics.
>
> The generated code is relevant too of course but it's fairly mechanically 
> obvious (ignoring tedious details :) ) how to translate basic parametric 
> polymorphism or basic adhoc.  In the dictionaries approach above this seems 
> similar to how Haskell implements typeclasses but for implicitly satisfied 
> constraints (from the contract).
>
> Initially I didn't like the contracts proposal but the more I think of it 
> in the way of implicitly generating types (and esp. typeclass-like 
> constructs) the more I like it and the more it feels like Go where 
> interfaces are implicitly satisfied.
>
> Cheers,
>
> Jamie  
>
> On Thursday, November 1, 2018 at 10:30:30 AM UTC, Mandolyte wrote:
>>
>> You can use https://github.com/albrow/fo and see what code it generates. 
>> Conceptually, I imagine will it be close to what the draft spec would 
>> produce. Some differences and limitations:
>> - it uses square brackets instead of (type .. ) for the type parameters
>> - it is limited to a single main() package
>> - doesn't use contracts (but not relevant for your question since 
>> contracts are for compile time)
>>
>> On Tuesday, October 30, 2018 at 12:14:42 PM UTC-4, Jamie Clarkson wrote:
>>>
>>> Replying to myself but I've got a different method with a dictionary per 
>>> type instead of the interface per value:
>>>
>>> iv) Dictionary based: https://play.golang.org/p/t6GBTEgq_g6
>>>
>>> (that one based on reflect but could use the slice interfaces or similar)
>>>
>>> On Tuesday, October 30, 2018 at 3:39:09 PM UTC, Jamie Clarkson wrote:
>>>>
>>>> Ah ok, sorry I don't want to waste your time getting into the 
>>>> nitty-gritty of a hypothetical situation but are you meaning the 
>>>> code for (say):
>>>>
>>>> func (u *_UserEdge) Nodes() _SliceN {
>>>> nodes := u.UserEdge.Nodes() // type []UserNode
>>>> return _SliceUserNode(nodes)
>>>> }
>>>>
>>>> ?
>>>>
>>>> On Tuesday, October 30, 2018 at 3:19:42 PM UTC, Ian Lance Taylor wrote:
>>>>>
>>>>> On Tue, Oct 30, 2018 at 8:15 AM, Jamie Clarkson  
>>>>> wrote: 
>>>>> > 
>>>>> > I'm not sure what you meant by conversion of non-interface to 
>>>>> interface 
>>>>> > types to handle results?  I can see the usual conversions working 
>>>>> fine at 
>>>>> > the call site for input parameters but the actual ShortestPath func 
>>>>> seems to 
>>>>> > need to use interface throughout? 
>>>>>
>>>>> I mean in converting the slice returned by Edge.Nodes to the 
>>>>> implicitly generated slice interface type. 
>>>>>
>>>>> Ian 
>>>>>
>>>>

-- 
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] Code generated by generics draft

[Mandolyte]

I didn't encounter this when I experimented with the package (here 
<https://github.com/albrow/fo>). So not sure. However, as an array, T 
cannot be a variable, it must be a constant... so perhaps it can be figured 
out - see https://play.golang.org/

On Thursday, November 1, 2018 at 11:54:31 AM UTC-4, Ian Denhardt wrote:
>
> Quoting Mandolyte (2018-11-01 06:30:30) 
>
> > - it uses square brackets instead of (type .. ) for the type parameters 
>
> What does it do with `type Foo [T] int`? The draft design cites this 
> ambiguity (is it a generic type with an unused parameter, or an array of 
> length T?) as the reason for not using square brackets. 
>
> (Note that Alan Fox proposed elsewhere using [type T] to declare type 
> parameters as a solution, but it doesn't appear that Fo is doing this). 
>

-- 
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] Code generated by generics draft

[Mandolyte]

You can use https://github.com/albrow/fo and see what code it generates. 
Conceptually, I imagine will it be close to what the draft spec would 
produce. Some differences and limitations:
- it uses square brackets instead of (type .. ) for the type parameters
- it is limited to a single main() package
- doesn't use contracts (but not relevant for your question since contracts 
are for compile time)

On Tuesday, October 30, 2018 at 12:14:42 PM UTC-4, Jamie Clarkson wrote:
>
> Replying to myself but I've got a different method with a dictionary per 
> type instead of the interface per value:
>
> iv) Dictionary based: https://play.golang.org/p/t6GBTEgq_g6
>
> (that one based on reflect but could use the slice interfaces or similar)
>
> On Tuesday, October 30, 2018 at 3:39:09 PM UTC, Jamie Clarkson wrote:
>>
>> Ah ok, sorry I don't want to waste your time getting into the 
>> nitty-gritty of a hypothetical situation but are you meaning the 
>> code for (say):
>>
>> func (u *_UserEdge) Nodes() _SliceN {
>> nodes := u.UserEdge.Nodes() // type []UserNode
>> return _SliceUserNode(nodes)
>> }
>>
>> ?
>>
>> On Tuesday, October 30, 2018 at 3:19:42 PM UTC, Ian Lance Taylor wrote:
>>>
>>> On Tue, Oct 30, 2018 at 8:15 AM, Jamie Clarkson  
>>> wrote: 
>>> > 
>>> > I'm not sure what you meant by conversion of non-interface to 
>>> interface 
>>> > types to handle results?  I can see the usual conversions working fine 
>>> at 
>>> > the call site for input parameters but the actual ShortestPath func 
>>> seems to 
>>> > need to use interface throughout? 
>>>
>>> I mean in converting the slice returned by Edge.Nodes to the 
>>> implicitly generated slice interface type. 
>>>
>>> Ian 
>>>
>>

-- 
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] Proposed changes to the Go draft generics design in the light of feedback received

[Mandolyte]

Alan, like your approach and nearly all your solutions (any quibbling I have 
isn't worth mentioning). 

And best of all, I think it would make excellent godoc documentation.

Thanks for taking the time to write this up.

-- 
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] Scrapping contracts (was: "Generics as bultin typeclasses")

[Mandolyte]

On field accessors... 

- Algorithms for X,Y points requiring them to be members of a struct type.

- Algorithms to manipulate colors, requiring R,G, and B to be members.

In an image processing library with its own rich set of struct types, such 
accessors would prove productive.

Are these the kind of examples you meant?

-- 
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] A thought on contracts

[Mandolyte]

I think it worth noting that a contract also makes good documentation for 
godoc. Thus a win for all users of generic libraries.

-- 
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: Accessing Slices Made From Same Array Concurrently

[Mandolyte]

While not quite the same problem, this post describes something similar in 
concept, "banking strings" in a single large byte slice to avoid GC 
pressures.

https://syslog.ravelin.com/whats-all-that-memory-for-e89522e1c2c6

On Friday, April 20, 2018 at 11:26:08 PM UTC-4, Kaveh Shahbazian wrote:
>
> Is it safe to access slices that shares a back array concurrently? 
> (Assuming the length of slices will not change)
>
>
>

-- 
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: Help with XML parsing

[Mandolyte]

I have some utilities that should give you some help. Documented in three 
blog articles. Here is the first one.

http://www.mandolyte.info/2017/12/encodingxml.html

which points to a generic parser that can be used on any XML document (I 
think :-)) and outputs a CSV "report".

HTH,
Cecil

On Tuesday, April 3, 2018 at 4:47:49 PM UTC-4, XXX ZZZ wrote:
>
> Hello,
>
> I'm trying to parse an XML with golang but I'm having a hard time creating 
> a parser for the string, in fact I couldn't even get an output using 
> interface{}.
>
> package main
>
> import (
> "fmt"
> "encoding/xml"
> )
>
>
> type MMXML_Listing struct {
> Original_title string `xml:"title"`
> Original_desc   string `xml:"description"`
> Original_domain   string `xml:"displayurl"`
> Original_URL   string `xml:"clickurl"`
> }
>
> type MMXML_HostProperties struct {
> Tags[]MMXML_Listing`xml:"response>adverts>advert"`
> }
> const s = ` results="1" search="806848020741095496" query="whatsapp" country="XX" 
> platform="zzz" currency="USD" guid="FP.66.66.66.61"> provider="0" bid="1" campaign="1" copy="1" network="1" sector="0" 
> ecpmi="1000">AdvertTitleAdvertSummaryClickThroughURL
> http://feed.domain.net/click.ashx?sys=aaae=sBG08dZWyRwhRESxvC6tX6WzJWV8BdmTrS%2bTR5ER3iawNpt8CrWuXiUojalDVLd%2b0mecpq8jjsCmDIKOgWIVyMkLLh4%2f6XAsMfxC535sUJC%2fb2agNsARWsEYXrPgvu%2b9sBPCJWM6YQUuN8PWqP1k8MTFpq0XwVGgGcSs03i6VRu61q9oC6JSVpARh44Sx10YOnY1Clsm24833w3TAYm0QqPDOVLMMKqrQErT0n66okBFchacKl2EhZy64VnpzJI4xJRaL%2bkavtFnsX18b6bPl0PWJadPPz%2fZ%2fe7cpS7U7qiT74wIIPwBNkoxCBLO7xqT4E8t62OSIRpUTgMxYY4Z9REWoGZYBq%2fyox8YGTV509gknMpdzQfY9uBKEj5BZgNmzkzozVelNi0agbsdLEbWhQ%3d%3d
> StandardText`
>
> func main() {
> r := MMXML_HostProperties {}
> err := xml.Unmarshal([]byte(s), )
> if err != nil {
> panic(err)
> }
> fmt.Printf("%+v", r)
> }
>
> playground: https://play.golang.org/p/BbsrKYFPj5-
>
> Basically I want to get the elements within "advert" tag, however it 
> always returns empty. Any ideas why?
>
> As for the "bid" attribute within "adverts" tag, what would be the 
> appropiate approach?
>
> Thanks in advance.
>
>
>

-- 
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: All Forms of Wishful Generics

[Mandolyte]

+1

On Monday, February 19, 2018 at 12:37:14 PM UTC-5, Michael Jones wrote:
>
> Matthew Juran wrote: *"...but if you use maps, slices, append, make, you 
> are already using generics."*
>
> This seems deeply insightful to me. Perhaps a better question than the 
> self-defeatingly open question of "how should Go embrace generics?" would 
> be "what change would allow maps, slices, append, and make to be 
> implemented as user code in Go 2?"
>
> On Mon, Feb 19, 2018 at 8:53 AM,  
> wrote:
>
>> I would probably never use it, like many people who comes to Go from C.
>>
>>
>> But if you use maps, slices, append, make, you are already using generics.
>>
>> Maybe this is unfounded, but I'm far from convinced that generics would 
>>> make my experience of Go better. I'm really thinking here of, are we really 
>>> sure they would make large unfamiliar codebases more comprehensible? Every 
>>> feature of a language can be abused, so are they worth the abuse that they 
>>> would allow?
>>
>>
>> Sometimes having another built-in function would be helpful, and generics 
>> would provide a way to write those without changing the compiler. What I’ve 
>> seen is that built-in functions and new types expanding on the map/slice 
>> pattern will not make it into Go 2 without a major reason.
>>
>> The other call for generics is interface{}. The Go 1 uses of interface{} 
>> can make strange code that maybe would be more comprehensible another way.
>>
>> Matt
>>
>> On Monday, February 19, 2018 at 9:50:53 AM UTC-6, Henrik Johansson wrote:
>>>
>>> I disagree that generics would decrease readability at the call site. 
>>> Perhaps within the library where it is used but maybe not even there. The 
>>> only complexity is within the compiler and other internals. This is not 
>>> irrelevant by far but the carte blanche "generics is bad" is most often 
>>> hyperbole.
>>>
>>> I can also "do without" generics and in fact even though Go lacks it I 
>>> prefer Go to all other languages that I know. I still would appreciate a 
>>> generics version in Go's spirit.
>>>
>>> On Mon, Feb 19, 2018, 16:06 Ignazio Di Napoli  wrote:
>>>

 On Monday, February 19, 2018 at 4:04:12 PM UTC+1, Ignazio Di Napoli 
 wrote:
>
> data2 := found.(float32)   // THIS PANICS AT RUNTIME, data2 is int
>

 Sorry, found is int. 

 -- 
 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...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Michael T. Jones
> michae...@gmail.com 
>

-- 
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] All Forms of Wishful Generics

[Mandolyte]

I think this falls into a variation of package level generics.

Look over the document below and see if there is any changes you would 
recommend.

https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit?usp=drivesdk

Thanks for sharing!

-- 
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] [Question] database/sql

[Mandolyte]

Yeah, makes sense... I was just trying to do something I could do in 
Java... but it's interpreted and isn't creating an executable.

No biggie... just wanted to be sure I wasn't overlooking any tricks. 

Thanks for the quick answer!

On Thursday, February 8, 2018 at 8:39:02 AM UTC-5, Jan Mercl wrote:
>
> On Thu, Feb 8, 2018 at 2:29 PM Mandolyte <ceci...@gmail.com > 
> wrote:
>
> > I want to load it at run time. Is this possible? 
>
> Why? The driver code is already linked into your program, otherwise you 
> would not be able to load it later.
>
> -- 
>
> -j
>

-- 
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] [Question] database/sql

[Mandolyte]

I'd like to use the same program against multiple databases and set the 
driver by configuration. But since the driver is in the source code, I 
don't see a way to do that.

In other words, I don't want to include this in my code:

> import (
> _ "github.com/lib/pq"
> )


I want to load it at run time. Is this possible?

-- 
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: Announcing gophersat, a SAT and Pseudo-Boolean solver, v1.0.0

[Mandolyte]

Fabien, you mention below that generics would help... I encourage you to 
make a fuller description of why/how generics would help and update this 
wiki page to point to it:
https://github.com/golang/go/wiki/ExperienceReports#generics


On Thursday, December 21, 2017 at 8:25:53 PM UTC-5, Fabien wrote:
>
> Short answer : according to the few tests I ran, they are pretty close. 
> You can use any of them, or, even better, both of them.
>
> Long answer :
>
> I have only compared them on about a dozen industrial problems, so take it 
> with a grain of salt, but it's hard to name a winner. Gini is usually a 
> little faster, but when it is slower, it is way slower than Gophersat. Gini 
> is very good (sometimes even better than state-of-the-art C++ solvers, like 
> glucose) on some very easy problems (those that can be solved in about 10 
> to 50 ms), probably because it has a very good parser and low warmup costs. 
> But it is not as good on harder problems, and it can only deal with pure 
> SAT, CNF problems (and they can be exponentially bigger than their 
> pseudo-boolean counterparts).
>
> So, if you must solve hundreds of easy problems in a second, and if your 
> problem is described as a CNF and you have no control over that, picking 
> gini might be a good choice. If your problem is a little harder, or if you 
> have the possibility to describe it as a pseudo-boolean problem, gophersat 
> will probably be better.
>
> Since they are not efficient on the same kinds of problems, using both of 
> them concurrently might be interesting, too. Making them solve the same 
> problem and stop them when an answer was found.
>
> When solving pure CNF problems, the current version of gophersat suffers 
> from the fact that it can natively deal with cardinality constraints and 
> pseudo-boolean constraints: binary clauses take a lot of space in memory, 
> and a lot of time is spent in the solver figuring out whether we are 
> dealing with a clause or a more complex constraint. In the next future, we 
> will probably include the ability to compile an optimized version of the 
> solver for pure sat problems via build tags. Having generics in the 
> language would solve that issue too ;)
>
> Le jeudi 21 décembre 2017 16:44:24 UTC+1, Damian Gryski a écrit :
>>
>> How does it compare to https://github.com/IRIFrance/gini ?
>
>

-- 
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 and cygwin!

[Mandolyte]

If not wedded to cigwin try git bash. I liked it much better personally and it 
gave most of the same benefits

-- 
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] XML Pretty Print

[Mandolyte]

I was able to do a minimalist pretty print with limitations just using 
marshal/unmarshal. See the code here 
<https://github.com/mandolyte/xml-utils> under the "identityXform" folder. 
There is a "readme" in that folder with some notes on this. Also tried my 
hand at blogging about my findings http://www.mandolyte.info.

Thanks all for responses.
Cecil

On Monday, December 11, 2017 at 11:38:44 AM UTC-5, Sam Whited wrote:
>
> On Mon, Dec 11, 2017, at 09:12, Mandolyte wrote: 
> > At my previous company I had a Go program that would take any XML 
> > document 
> > and output it as XML in a nicer human readable format, i.e., pretty 
> > printed. I've trying to find it again, but my searches have not turned 
> up 
> > any. Perhaps I had written myself, but I didn't think so. 
> > 
> > Does anyone have a link to one? 
>
> My xmlstream package contains a formatting transformer that might do 
> what you want: 
>
> https://godoc.org/mellium.im/xmlstream 
>
> Note that this was written to test some changes for Go 1.10 and it may 
> only build there. 
>
> —Sam 
>

-- 
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] XML Pretty Print

[Mandolyte]

At my previous company I had a Go program that would take any XML document 
and output it as XML in a nicer human readable format, i.e., pretty 
printed. I've trying to find it again, but my searches have not turned up 
any. Perhaps I had written myself, but I didn't think so.

Does anyone have a link to one?

Thanks in advance,
Cecil

-- 
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: Gremlin go client...

[Mandolyte]

I have used the qasaur package, but it has been a while. At the time, I 
filed an issue to bring it up to date to the then current version of 
gremlin. The package is pretty small and the interactions with the gremlin 
server are pretty simple. It worked ok for the simple things I was doing at 
the time (mostly around recursion for product type data).

On Saturday, October 21, 2017 at 12:24:00 PM UTC-4, forfader wrote:
>
> I need gremlin client to access JanusGraph graph database from Go. I'll be 
> using the JanusGraphServer configuration.
>
> I'm always amazed at the broad range of open source go libraries. This is 
> the first time that I've come up wanting, when looking for a go open source 
> library.
>
> I found the following two, neither of which looks particular active or 
> mature.
>
> https://github.com/go-gremlin/gremlin
> https://github.com/qasaur/gremgo
>
> Has anyone had experience with either of these?
>
> Is there another library out there?
>
> Thanks,
> Michael-
>

-- 
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] Go on ARM 32bit and 64bit resources and groups

[Mandolyte]

Slightly different question... would this ARM approach work on a Samsung 
Chromebook Plus which uses OP1 ARM, with Crouton installed?

-- 
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] Today I discovered another std lib gem: strings.NewReplacer

[Mandolyte]

Thanks for sharing! I can use this to simply some Go code

-- 
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] Teaching Go Experience

[Mandolyte]

The experience reports 
at https://github.com/golang/go/wiki/ExperienceReports include a reference 
to an article on experience and recommendations for Go2 from CMU. Good read!

Direct link:
http://www.monogrammedchalk.com/go-2-for-teaching/

Thanks to Carl Kingsford for the write up.

-- 
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] Question on os.Cmd() and go routines

[Mandolyte]

I have a command line program (Java with mostly network i/o) that I must 
run several 100K times each with its own input. Wondered whether external 
commands are amenable to concurrency? Or whether best to run multiples 
copies dividing up the inputs so each copy has its own, say 100K values?

Any words of wisdom before I start experimenting?

-- 
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] Concurrency Testimonial

[Mandolyte]

This past week I wrote an "audit" program for management to see how a long 
running data migration effort was going (it will take several months to 
complete). I was little discouraged when I found that the audit was on pace 
to complete in 10 days. That got me to thinking of making a concurrent 
version of the code. It's been over a year since I last did anything with 
channels, so I spent some time studying my previous examples, did some 
google searches, etc.

In just a few hours I had it converted, only had a single deadlock bug to 
figure out. Found that it was very easy to reason about. I made it so it 
could use an argument specified number of go routines. With 10 concurrent 
go routines, it is on pace to complete in less than 32 hours.

So just a big thank you for such a nice language!

-- 
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] Ellipse use error

[Mandolyte]

This line of code:
retrTarget := path.Join(maindir, ss[0], pathparts[npp:]...)

produces this error:
.\xxx.go:131: too many arguments in call to path.Join
have (string, string, []string...)
want (...string)

Easy to work around, but I don't understand why it doesn't work... 

Thanks for insights!
Cecil

-- 
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: Generics are overrated.

[Mandolyte]

It's been many years since I was involved in developing complex systems 
(C++ and Java). But I agree, it was mostly lists and sets with searching 
and sorting. But I also used them for algorithms a good bit. Thus I would 
guess that the maintainers of GONUM libraries might benefit (anyone 
confirm?).

I haven't seen many libraries developed in Go yet, but I think it likely 
many would benefit from generics. And I think it could simple and readable. 
I tend to think of it as an analogue to `go generate`. The latter is for 
package *authors*... a similar feature for package *users *is all that is 
needed.

On Sunday, July 30, 2017 at 5:08:46 PM UTC-4, David Collier-Brown wrote:
>
> I came to Go from languages that had generics, but in practice I find that 
> I predominantly used list-of and  set-of.  And I spent a dispropriate 
> amount of time with valgrind making sure my C++ list didn't have leaks (:-()
>
> A question to people who use Java/C++ and friends: what generics do you 
> find you use in *production* programs?
>
> --dave
>

-- 
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: Generics are overrated.

[Mandolyte]

Just a reminder that Egon Elbre's documentation of all the discussions on 
this topic is here:

https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4


-- 
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] Web UI library in pure Go?

[Mandolyte]

https://github.com/gopherjs/gopherjs

On Saturday, July 15, 2017 at 5:16:34 PM UTC-4, ohir wrote:
>
> On Sat, 15 Jul 2017 09:30:39 -0700 (PDT) 
> Leff Ivanov  wrote: 
>
> > Is there something like Vaadin, GWT, ZK in Golang world? I mean 
> something 
> > to do web UIs in pure Go without the need to write JavaScript and HTML. 
> > 
>
> https://github.com/icza/gowut GPL3 
> https://github.com/gu-io/gu MIT 
>
>

-- 
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: {CGO,VM}-free SQLite (ATM Linux/Intel only, pre-alpha)

[Mandolyte]

By the name and the reference to the SQLite3 website for documentation, I 
think is intended to be a pure (?) Go driver for the SQLite3 file format. 
But I also noticed some references to C runtime... so just wanted to make 
sure I understood the intent.

thanks.

On Monday, June 5, 2017 at 2:30:18 PM UTC-4, Jan Mercl wrote:
>
> https://github.com/cznic/sqlite
>
> -- 
>
> -j
>

-- 
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: Last Gasp Call for Native Decimal Support

[Mandolyte]

Doesn't help with operators, but noticed this:
https://www.cockroachlabs.com/blog/apd-arbitrary-precision-decimal-package/

On Wednesday, March 29, 2017 at 1:27:22 PM UTC-4, a.mat...@ra-micro.de 
wrote:
>
>
> No!
>
>
> We want to use operators like + , - , *  and /  with decimal values. This 
> is actualy a "No Go" !
>

-- 
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] XML Stream Parser examples

[Mandolyte]

First, never thought I'd have to parse XML again (it's been over 10 years), 
but life happens...

After a lot of searching I found only few examples using the streaming API. 
But I'm not sure the examples will work for me (I'll find out more tomorrow 
when I get back to the office). The XML I must parse is deeply nested with 
the same element nodes at different levels; it is in general a bit 
unpredictable. It is, in essence, a set of rules for rules engine/wizard. 
The files are moderate in size; I have seen any over 10K lines pretty 
printed yet.

I need to parse to find a known element, then based on what I find, decode 
its children elements. This implies I need to treat the child elements as a 
document (may have to add a fake root node, unless the decoder accepts 
sequences). But I haven't seen any examples of such an approach.

Thanks for any advice!
Cecil

-- 
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] Algorithm Club

[Mandolyte]

The recent survey reveled that generics was thing that would improve Go the 
most. But at 16%, the responses were rather spread out and only 1/3 seemed 
to think that Go needed any improvement at all - see link #1. I think most 
will concede that generics would help development of algorithms, libraries, 
and frameworks. So in the spirit of friendly rivalry, here is a list of 
algorithms developed for Swift:

https://github.com/raywenderlich/swift-algorithm-club

As you might guess, it is chock-full of generics. Yeah, I'm a little 
envious. :-) enjoy...



#1 https://blog.golang.org/survey2016-results

-- 
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: Code review/Advice - reading and editing a CSV

[Mandolyte]

I deal with CSV files a lot. I have made most available here:

https://github.com/mandolyte/csv-utils

Hope it helps,
Cecil

-- 
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] Question on lib/pq CopyInSchema

[Mandolyte]

I have a date column which isn't fully populated. I tried to use "\N" per 
(1) and also just an empty string. Neither worked, both giving this error: 

invalid input syntax for type date


Is there a way to supply null values for CopyInSchema?

-- 
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] How to pass a go file name as arguments to go run

[Mandolyte]

Pass as a value to a named argument: 
go run cmd/main.go -input tests/dir/a.go

-- 
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: Channels and Networks together

[Mandolyte]

Not to my knowledge. But if your goal is distributed computing, then take a 
look at https://github.com/chrislusf/glow

On Wednesday, December 14, 2016 at 1:03:41 PM UTC-5, Junaid Farooq wrote:
>
> Hi eveyone, Very new to #GoLang. have been doing Elixir / Ruby / PHP and 
> etc stuff for past 4 years.
>
> I was listening to the talk meet Go Lang. in which Rob Pike mentioned 
> that, He and Ken talked a lot about getting Channels and networks together, 
> but they still didnt, and he mentioned erlang has done that but it has 
> different model structure.
>
> The talk was very long time ago, what is the current status of this issue? 
> 
>
> Go lang has done something in this? Channels and Networks together ? 
>

-- 
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: Large 2D slice performance question

[Mandolyte]

This worked out well. I was able to "materialize" over 1200 trees in under 
an hour. Pretty amazing. I didn't end up using the DenseSet code. Your 
quick and dirty version only handled cycles starting from start value. But 
other than that the concept worked out very well.

I did try a version with multiple go routines, but found that they hurt 
performance. It was much faster without them. I think the learning here is 
that if the code is solely working in-memory, then go routines/channels 
aren't going to help. In fact, a few times I had strange messages come out 
on the console, which I think were due to starved channels. 

The full test resulted in over 700M paths being generated... impressive!

Thanks very much for the advice!

On Thursday, December 1, 2016 at 6:45:02 AM UTC-5, Mandolyte wrote:
>
> Wow, this will take some time to digest. Regrettably I have required 
> training today and won't be able to even play with this until tomorrow.
>
> In my (parent,child), there are 304K unique parent values and 1.05M unique 
> child values. Of course many child values are also parent values. Thus, 
> total names are only just over 1.14M.
>
> This data came from and will go back to a database and it must be correct 
> CSV. And I know there is data that needs to be escaped per RFC 4180. Also, 
> I had always thought that the CSV package was buffered since it has a 
> Flush() method (and if not used, you will lose data!). At any rate, I'm 
> reluctant to roll my own here since I've been bitten too many times by the 
> data content.
>
> Thanks for taking the time to review this!
>
> On Thursday, December 1, 2016 at 4:21:42 AM UTC-5, Egon wrote:
>>
>> See whether this works better: 
>> https://gist.github.com/egonelbre/d94ea561c3e63db009718e227e506b5b 
>> <https://www.google.com/url?q=https%3A%2F%2Fgist.github.com%2Fegonelbre%2Fd94ea561c3e63db009718e227e506b5b=D=1=AFQjCNFNg8SS63IgRFvzKRY9YYifLjdsMg>
>>
>> *There is a lot of room for improvements, (e.g. for your actual dataset 
>> increase defaultNameCount).*
>>
>> *PS: Avoid csv package for writing files, use bufio and Write directly... 
>> csv does some extra stuff, that you probably won't need.*
>>
>> btw. how many different names do you have?
>>
>> + Egon
>>
>> On Thursday, 1 December 2016 02:51:49 UTC+2, Mandolyte wrote:
>>>
>>> Thanks for the discussion! Package with tester is at:
>>> https://github.com/mandolyte/TableRecursion
>>>
>>> While I can't share the data, I could take a sample set of paths for a 
>>> root node, reverse engineer the pairs, and obfuscate... I've done this sort 
>>> of thing before but it is a bit of work. So I'll treat that as a last 
>>> resort. :-)
>>>
>>> On Wednesday, November 30, 2016 at 5:36:41 PM UTC-5, Mandolyte wrote:
>>>>
>>>> The finite set idea might work, but the set is well over 300K. The 
>>>> strings (part numbers) are not regular.
>>>>
>>>> I could make a single pass over the "parent" column and record in a 
>>>> map[string]int the index of the first occurrence. Then I would avoid 
>>>> sort.Search() having to find it each time. Or use sort.Search() on the 
>>>> smaller 300K slice if map performance was a problem...
>>>>
>>>> There is a lot of repetition in the "branches" - perhaps some caching 
>>>> would be appropriate...
>>>>
>>>> thanks for the ideas!
>>>>
>>>> On Wednesday, November 30, 2016 at 9:31:56 AM UTC-5, adon...@google.com 
>>>> wrote:
>>>>>
>>>>> On Wednesday, 30 November 2016 03:37:55 UTC+2, Mandolyte wrote:
>>>>>>>
>>>>>>> I have a fairly large 2D slice of strings, about 115M rows. These 
>>>>>>> are (parent, child) pairs that, processed recursively, form a tree. I 
>>>>>>> am 
>>>>>>> "materializing" all possible trees as well as determining for each root 
>>>>>>> node all child nodes for all levels for it.
>>>>>>>
>>>>>>  
>>>>> In addition to what Egon said:
>>>>>
>>>>> If the elements of the outer [][]string slice are all []string slices 
>>>>> of length 2, it would be much more efficient to use [2]string instead, 
>>>>> that 
>>>>> is, fixed-sized arrays of two strings, since this would avoid a lot of 
>>>>> memory allocation and pointer indirection.  The type of the outer slice 
>>>>> would become [][2]string.
>>>>>
>>>>> Also, if all your strings are drawn from a finite set, you'll find 
>>>>> many operations (such as comparison or set membership tests) much more 
>>>>> efficient if you represent each string by its index in some side table. 
>>>>>  Then instead of [2]string you can use [2]uint32, or perhaps even a 
>>>>> narrower integer type, which will make your main array more compact by at 
>>>>> least a factor of 4.
>>>>>
>>>>>

-- 
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 @ Work

[Mandolyte]

Will ActiveGo come packaged with common database drivers Oracle, 
Postgresql, etc. and the usual assortment of NoSQL databases?

On Thursday, December 8, 2016 at 12:55:57 PM UTC-5, je...@activestate.com 
wrote:
>
>
>
> On Friday, March 30, 2012 at 10:27:36 AM UTC-7, hcatlin wrote:
>>
>> Just thought I'd stop in and post something saying "hi" to the group. 
>> I work at 
>> Moovweb where we power some of the biggest e-commerce sites' mobile 
>> experience 
>> on our platform. Our platform has super strong demands on it and our 
>> business is 
>> growing at a nearly exponential rate. 
>>
>> This past summer, I made the decision to switch all of our internal 
>> software to Go 
>> after being persuaded by our Senior Architect, Zhigang Chen. Of 
>> course, knowing that Go 
>> was beta and that the future of the company was being bet on Go was 
>> (and is) amazingly 
>> stressful. 
>>
>> The library ecosystem was a little weak for our needs when we first 
>> showed up so 
>> we've since released a Regexp library called Rubex that makes regular 
>> expressions 
>> 2-3x faster, we've released Gokogiri which is a libxml wrapper library 
>> for XML/HTML 
>> parsing, and GVM the go version manager so that we can work with code 
>> bases 
>> on various versions of Go. 
>>
>> A couple observations: 
>> * New users/employees have learned Go very quickly. +20! 
>> * Found out about breakage in 32-bit while in production. -10! 
>> * Had to write our own libraries for some basic stuff. -5! 
>> * Performs very well in production (only on 64-bit). +10! 
>>
>> Man, so much to say... this bullet list might go on and on. 
>>
>> I mostly just wanted to say that to us Go is not a hobbyist language. 
>> Its a complex 
>> build environment for us with dependency management and 5 full time 
>> developers 
>> writing code daily in it. 
>>
>> We didn't build "some small part" of our platform in Go... its the 
>> heart of our tech. 
>> Our SDK is a compiled binary that we are packaging and sending out to 
>> our 
>> clients and integration partners. Our production system is handling 
>> millions of pages 
>> a day and millions of dollars of ecommerce a month. 
>>
>> We've bet on Go big time... and will continue to bet on it. We will 
>> continue to release 
>> new code and we will continue to try and mature the community and tool 
>> set so that 
>> we can deal with real life issues. 
>>
>> I'd love to hear if other companies are doing a similar thing. 
>>
>> http://site.moovweb.com // public site 
>> http://github.com/moovweb // public software repo 
>>
>> -hampton (@hcatlin) 
>>
>>
>> Hi  Hampton,
>
> I can assure you some big bets are being laid on Go as it has so much 
> going for it. My thoughts are here (I'm product guy at ActiveState) and why 
> we at ActiveState are "all-in" on Go: http://bit.ly/2gD4zxp 
> 
>
> Cheers,
>
> -JR
>

-- 
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: Large 2D slice performance question

[Mandolyte]

Wow, this will take some time to digest. Regrettably I have required 
training today and won't be able to even play with this until tomorrow.

In my (parent,child), there are 304K unique parent values and 1.05M unique 
child values. Of course many child values are also parent values. Thus, 
total names are only just over 1.14M.

This data came from and will go back to a database and it must be correct 
CSV. And I know there is data that needs to be escaped per RFC 4180. Also, 
I had always thought that the CSV package was buffered since it has a 
Flush() method (and if not used, you will lose data!). At any rate, I'm 
reluctant to roll my own here since I've been bitten too many times by the 
data content.

Thanks for taking the time to review this!

On Thursday, December 1, 2016 at 4:21:42 AM UTC-5, Egon wrote:
>
> See whether this works better: 
> https://gist.github.com/egonelbre/d94ea561c3e63db009718e227e506b5b
>
> *There is a lot of room for improvements, (e.g. for your actual dataset 
> increase defaultNameCount).*
>
> *PS: Avoid csv package for writing files, use bufio and Write directly... 
> csv does some extra stuff, that you probably won't need.*
>
> btw. how many different names do you have?
>
> + Egon
>
> On Thursday, 1 December 2016 02:51:49 UTC+2, Mandolyte wrote:
>>
>> Thanks for the discussion! Package with tester is at:
>> https://github.com/mandolyte/TableRecursion
>>
>> While I can't share the data, I could take a sample set of paths for a 
>> root node, reverse engineer the pairs, and obfuscate... I've done this sort 
>> of thing before but it is a bit of work. So I'll treat that as a last 
>> resort. :-)
>>
>> On Wednesday, November 30, 2016 at 5:36:41 PM UTC-5, Mandolyte wrote:
>>>
>>> The finite set idea might work, but the set is well over 300K. The 
>>> strings (part numbers) are not regular.
>>>
>>> I could make a single pass over the "parent" column and record in a 
>>> map[string]int the index of the first occurrence. Then I would avoid 
>>> sort.Search() having to find it each time. Or use sort.Search() on the 
>>> smaller 300K slice if map performance was a problem...
>>>
>>> There is a lot of repetition in the "branches" - perhaps some caching 
>>> would be appropriate...
>>>
>>> thanks for the ideas!
>>>
>>> On Wednesday, November 30, 2016 at 9:31:56 AM UTC-5, adon...@google.com 
>>> wrote:
>>>>
>>>> On Wednesday, 30 November 2016 03:37:55 UTC+2, Mandolyte wrote:
>>>>>>
>>>>>> I have a fairly large 2D slice of strings, about 115M rows. These are 
>>>>>> (parent, child) pairs that, processed recursively, form a tree. I am 
>>>>>> "materializing" all possible trees as well as determining for each root 
>>>>>> node all child nodes for all levels for it.
>>>>>>
>>>>>  
>>>> In addition to what Egon said:
>>>>
>>>> If the elements of the outer [][]string slice are all []string slices 
>>>> of length 2, it would be much more efficient to use [2]string instead, 
>>>> that 
>>>> is, fixed-sized arrays of two strings, since this would avoid a lot of 
>>>> memory allocation and pointer indirection.  The type of the outer slice 
>>>> would become [][2]string.
>>>>
>>>> Also, if all your strings are drawn from a finite set, you'll find many 
>>>> operations (such as comparison or set membership tests) much more 
>>>> efficient 
>>>> if you represent each string by its index in some side table.  Then 
>>>> instead 
>>>> of [2]string you can use [2]uint32, or perhaps even a narrower integer 
>>>> type, which will make your main array more compact by at least a factor of 
>>>> 4.
>>>>
>>>>

-- 
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: Large 2D slice performance question

[Mandolyte]

Thanks for the discussion! Package with tester is at:
https://github.com/mandolyte/TableRecursion

While I can't share the data, I could take a sample set of paths for a root 
node, reverse engineer the pairs, and obfuscate... I've done this sort of 
thing before but it is a bit of work. So I'll treat that as a last resort. 
:-)

On Wednesday, November 30, 2016 at 5:36:41 PM UTC-5, Mandolyte wrote:
>
> The finite set idea might work, but the set is well over 300K. The strings 
> (part numbers) are not regular.
>
> I could make a single pass over the "parent" column and record in a 
> map[string]int the index of the first occurrence. Then I would avoid 
> sort.Search() having to find it each time. Or use sort.Search() on the 
> smaller 300K slice if map performance was a problem...
>
> There is a lot of repetition in the "branches" - perhaps some caching 
> would be appropriate...
>
> thanks for the ideas!
>
> On Wednesday, November 30, 2016 at 9:31:56 AM UTC-5, adon...@google.com 
> wrote:
>>
>> On Wednesday, 30 November 2016 03:37:55 UTC+2, Mandolyte wrote:
>>>>
>>>> I have a fairly large 2D slice of strings, about 115M rows. These are 
>>>> (parent, child) pairs that, processed recursively, form a tree. I am 
>>>> "materializing" all possible trees as well as determining for each root 
>>>> node all child nodes for all levels for it.
>>>>
>>>  
>> In addition to what Egon said:
>>
>> If the elements of the outer [][]string slice are all []string slices of 
>> length 2, it would be much more efficient to use [2]string instead, that 
>> is, fixed-sized arrays of two strings, since this would avoid a lot of 
>> memory allocation and pointer indirection.  The type of the outer slice 
>> would become [][2]string.
>>
>> Also, if all your strings are drawn from a finite set, you'll find many 
>> operations (such as comparison or set membership tests) much more efficient 
>> if you represent each string by its index in some side table.  Then instead 
>> of [2]string you can use [2]uint32, or perhaps even a narrower integer 
>> type, which will make your main array more compact by at least a factor of 
>> 4.
>>
>>

-- 
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: Large 2D slice performance question

[Mandolyte]

The finite set idea might work, but the set is well over 300K. The strings 
(part numbers) are not regular.

I could make a single pass over the "parent" column and record in a 
map[string]int the index of the first occurrence. Then I would avoid 
sort.Search() having to find it each time. Or use sort.Search() on the 
smaller 300K slice if map performance was a problem...

There is a lot of repetition in the "branches" - perhaps some caching would 
be appropriate...

thanks for the ideas!

On Wednesday, November 30, 2016 at 9:31:56 AM UTC-5, adon...@google.com 
wrote:
>
> On Wednesday, 30 November 2016 03:37:55 UTC+2, Mandolyte wrote:
>>>
>>> I have a fairly large 2D slice of strings, about 115M rows. These are 
>>> (parent, child) pairs that, processed recursively, form a tree. I am 
>>> "materializing" all possible trees as well as determining for each root 
>>> node all child nodes for all levels for it.
>>>
>>  
> In addition to what Egon said:
>
> If the elements of the outer [][]string slice are all []string slices of 
> length 2, it would be much more efficient to use [2]string instead, that 
> is, fixed-sized arrays of two strings, since this would avoid a lot of 
> memory allocation and pointer indirection.  The type of the outer slice 
> would become [][2]string.
>
> Also, if all your strings are drawn from a finite set, you'll find many 
> operations (such as comparison or set membership tests) much more efficient 
> if you represent each string by its index in some side table.  Then instead 
> of [2]string you can use [2]uint32, or perhaps even a narrower integer 
> type, which will make your main array more compact by at least a factor of 
> 4.
>
>

-- 
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: Large 2D slice performance question

[Mandolyte]

I'll try to get it out on Github tonight. It will have a little test 
program so you can see what it generates.

Will post again when it's there.

On Wednesday, November 30, 2016 at 11:28:16 AM UTC-5, Michael Jones wrote:
>
> Yes…the more that you can share the better our help will be. If you have a 
> small, even synthetic example of before and after we can do our best.
>
>  
>
> *From: *adonovan via golang-nuts <golan...@googlegroups.com >
> *Reply-To: *<adon...@google.com >
> *Date: *Wednesday, November 30, 2016 at 6:31 AM
> *To: *golang-nuts <golan...@googlegroups.com >
> *Subject: *[go-nuts] Re: Large 2D slice performance question
>
>  
>
> On Wednesday, 30 November 2016 03:37:55 UTC+2, Mandolyte wrote:
>
> I have a fairly large 2D slice of strings, about 115M rows. These are 
> (parent, child) pairs that, processed recursively, form a tree. I am 
> "materializing" all possible trees as well as determining for each root 
> node all child nodes for all levels for it.
>
>  
>
> In addition to what Egon said:
>
>  
>
> If the elements of the outer [][]string slice are all []string slices of 
> length 2, it would be much more efficient to use [2]string instead, that 
> is, fixed-sized arrays of two strings, since this would avoid a lot of 
> memory allocation and pointer indirection.  The type of the outer slice 
> would become [][2]string.
>
>  
>
> Also, if all your strings are drawn from a finite set, you'll find many 
> operations (such as comparison or set membership tests) much more efficient 
> if you represent each string by its index in some side table.  Then instead 
> of [2]string you can use [2]uint32, or perhaps even a narrower integer 
> type, which will make your main array more compact by at least a factor of 
> 4.
>
>  
>
> -- 
> 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...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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] goroutine/channel errors?

[Mandolyte]

Perfect! thanks for the quick reply.

On Wednesday, November 30, 2016 at 7:32:09 AM UTC-5, Jan Mercl wrote:
>
> On Wed, Nov 30, 2016 at 1:21 PM Mandolyte <ceci...@gmail.com > 
> wrote:
>
> > tr.sema <- struct{}{} 
>
> > What is this telling me? 
>
> The particular channel send operation was blocked for 595 minutes before 
> the stack trace was produced. It shows nothing is receiving from that 
> channel which might indicate a bug in the program or, less likely, in the 
> Go runtime scheduler.
>
> But it might be as well a completely valid program state. It depends on 
> what that send is meant to do and/or under what circumstances the receiver, 
> if any, should do the receive operation.
>
> Guessing from the channel name, I would investigate a suspected deadlock 
> state in the program on tr.sema.
>
>
>
> -- 
>
> -j
>

-- 
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] goroutine/channel errors?

[Mandolyte]

This morning a job that I had started last night was spitting out messages 
like this:

goroutine 23866180 [chan send, 595 minutes]

followed a stack trace, the first line number of which was pointing to this 
line of code:
tr.sema <- struct{}{}   

What is this telling me?

-- 
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: need library suggestions on writing a record program

[Mandolyte]

Also https://github.com/cznic/wm... It actually implements an event driven 
model. There's a demo that's easy to see what it can do.

-- 
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: Where to start to learn about Go compiler and others low level part?

[Mandolyte]

Here's a link to an article by someone else who went down this path and 
they explain a bit about how they went about going deeper...

http://thorstenball.com/blog/2016/11/16/putting-eval-in-go/

On Friday, November 18, 2016 at 10:41:57 PM UTC-5, nvcnvn wrote:
>
> All I ever do is some simple web applications or kind of microservice for 
> CMS stuff.
> Now I want to process to something deeper as a programmer. Everytime 
> reading Go core team discussion about compiler, GC... I know that serious 
> deep and complicate stuff. Now I have plenty of time and want to learn 
> about them but don't know where to start.
> My goal is spending next year to learn and hope can contribute even just a 
> small bit to the project.
> Please show me the paths to get there.
>
> Thanks!
>

-- 
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: Concurrent SQL queries with PG

[Mandolyte]

One of my worst case scenarios completed in less then 21 minutes. Very 
encouraging!! 

Suppose I opened two connections each running 10 threads, would I approach 10 
minutes? I'll give this a try later this week. This is pretty exciting for me 
since I never seen this problem solved in less than *hours*.

-- 
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: Concurrent SQL queries with PG

[Mandolyte]

Thanks for the quick response. and for your book - one of the best I've 
ever purchased!

To close the loop, optimal number of go routines is about 10 and the 
database is actually Greenplum, a massively parallel processing 
architecture based on an early fork of PG ... YMMV

On Monday, November 7, 2016 at 5:36:59 PM UTC-5, adon...@google.com wrote:
>
> On Monday, 7 November 2016 16:57:29 UTC-5, Mandolyte wrote:
>>
>> I have what amounts to a recursion problem and I wrote a minimal test 
>> using go routines. I am able to vary the max number of go routines as a 
>> parameter on the command line (*). But the times don't vary much whether a 
>> single go routine is used or 50 are used. I get the correct results, no 
>> matter how many are used.
>>
>> Are my expectations valid that I should be able to process faster with 
>> multiple go routines using the lib/pg driver? 
>>
>> Even a minimal tester for this got to almost 200 lines, but if it helps:
>> https://play.golang.org/p/y0cKhF7ujv
>>
>> Thanks for any advice...
>>
>>
>> (*) The structure of my code are based on the technique used in gopl.io 
>> in chapter 8, the concurrent filesystem directory traversal.
>>
>
> There's a bug in your code: numthreads is a pointer to an int variable 
> that is modified by the flag package during the call to flag.Parse, which 
> is usually the first thing done by main.  However, the channel you're using 
> as a counting semaphore is created during package initialization, before 
> main and the flag.Parse function are executed, so it always has the default 
> size of 20.  Create the channel after flag.Parse and see if that solves 
> your problem.
>
>

-- 
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] Concurrent SQL queries with PG

[Mandolyte]

I have what amounts to a recursion problem and I wrote a minimal test using 
go routines. I am able to vary the max number of go routines as a parameter 
on the command line (*). But the times don't vary much whether a single go 
routine is used or 50 are used. I get the correct results, no matter how 
many are used.

Are my expectations valid that I should be able to process faster with 
multiple go routines using the lib/pg driver? 

Even a minimal tester for this got to almost 200 lines, but if it helps:
https://play.golang.org/p/y0cKhF7ujv

Thanks for any advice...


(*) The structure of my code are based on the technique used in gopl.io in 
chapter 8, the concurrent filesystem directory traversal.

-- 
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: A proposal for generic in go

[Mandolyte]

On Saturday, July 2, 2016 at 9:12:54 AM UTC-4, Chad wrote:
>
>
>
> The appeal of generics is probably a false appeal.
>
> Then, if you accept the trilemma described at 
http://research.swtch.com/generic, that puts you in favor of "slow 
programmers"... just kidding. I went back to read all the comments from 
that blog post and found that it could have been written yesterday. Not 
much has changed since 2009. One commenter Rivorus 
 is very eloquent, 
favoring generics and points convincingly to the Boost Graph Library as why 
they are necessary. Others not so much. Pretty much like every thread on 
this topic when it comes up.

But I think the key is that Go's target of server side development rarely 
needs generics (think of Docker, Kubernetics, web server, etc.). However, 
just last April, Ian Lance Taylor stated forcefully "Go should support some 
form of generic programming. Generic programming enables the representation 
of algorithms and data structures in a generic form, with concrete elements 
of the code (such as types) factored out. It means the ability to express 
algorithms with minimal assumptions about data structures, and vice-versa." 
at https://github.com/golang/proposal/blob/master/design/15292-generics.md. 

This leads me to conclude that there are whole areas of software 
development that Go could impact significantly if it introduced generics. I 
think someone already pointed this out earlier in the thread, that this 
area is one of Libraries, Frameworks. This is an area of some controversy 
in the Go community. See, for instance, Doug Cheney's blog post 
at http://dave.cheney.net/2014/10/26/go-frameworks-and-ludditry.

But I'm with Ian on this point. Go needs it, but I'm content to wait for it 
to be done well.

-- 
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: GUI for Go

[Mandolyte]

I noticed that the QML project has been forked, so it may have some new energy

-- 
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.