Re: [go-nuts] Go and GPUs

[Tom Mitchell]

As others have said, lots of secret sauce which includes the instruction
set for the function blocks in silicon.
Thus there is no assembler for the compiler that generates the code.  Other
chunks of the necessary tool chain are also absent or homegrown (no
document other than source).

The best advice is to look at the installation scripts that bind secret
sauce to the exposed API wrapper.
Look at wrappers and install scripts for the same GPU on multiple systems
if you can.

Decades ago I had to be careful when debugging customer problems because
depending on the graphics engine you could walk down customer code to GL
library and system C and ASM code to a off the shelf digital signal
processor code and then custrom processors in VHDL. The C>hardware
transition was almost seamless to a reader with a good tag file and the
full source.  Functional symbols inside the graphics library drivers were
not intended to be used except by the GL but some were too tempting and
those symbols had to be edited out of shipped binary objects to clarify the
ABI and keep the system stable.

Ask nicely for help from the vendor.
I would assert() that GO could be more useful in large clusters of GPU rich
systems if facilitated.
Beware bogus asserts().



On Fri, Jun 25, 2021 at 8:52 AM Nikolay Dubina 
wrote:

> I tried to write down my own CUDA / NVIDIA GPU driver in native Go last
> weekend. To my great surprise, CUDA and pretty much all high performance
> software/hardware from NVIDIA is proprietary close-source C/C++ code.
> Meaning, you can't write native Go driver even if you wanted to. Forget Go,
> people are trying to reverse engineer it in C/C++ with limited success.
> From what I heard OpenCV is not a priority for NVIDIA either. Then I looked
> up what Apple is doing with their Neural Engine in latest chips. It too is
> closed-source Objective-C, Swift. I suspect situation with other powerful
> hardware is the same. Moore's law seem to be about GPU lately, and everyone
> is locking it in. Kind of not in the spirit open-source and Linux. That's
> quite bad state of affairs for Go and computing in general. Yikes!
>
> Just want to see what others are thinking.
>
> --
> 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/0913f098-700a-443f-bd02-2db7ad2408a6n%40googlegroups.com
> 
> .
>


-- 

  T o mM i t c h e l l  ( o n   N i f t y E g g )

-- 
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/CAAMy4URdwaqo-AF5-qZAS6GFEod8AF54X5uDBVAX%2BaeeTYCJBQ%40mail.gmail.com.

Re: [go-nuts] Re: Unable to find small memory leak

[Tom Mitchell]

On Thu, Feb 11, 2021 at 3:40 AM Uli Kunitz  wrote:

> You are writing: The device crashes with out of memory. What does crash?
> The Go program, another program or the kernel? Can you share the error
> message? Can you share the log file for one day of GODEBUG=gctrace=1?
>
> In bash do:
>
> $ export GODEBUG=gctrace=1
> $  2>error.log
>
> On Thursday, February 11, 2021 at 9:01:52 AM UTC+1 Miles Hex wrote:
>
>> To be honest, i'm not totally sure, what is see is that memory keep
>> raising until the device crash for out of memory, but what does it mean if
>> reachable object remain constant, but the " Heap objects" keep raising?
>>
>>> 
>>>
>>
Objects plural?
What is the size of each heap object.  With garbage collection it can help
to have as few sizes as possible. Pad objects so when collected the free
leaves a useful size space in the heap.   Linux can allow the VM system to
over allocate resources and only discover when written and the page fault
has no backing store.  Add swap to file and or tune the VM system.   Limits
-- set limits low enough for the program so it cannot dominate system
physical resources.
Add signal handler code to dump a summary of all your live objects.
Recursion? Socket(state)? Events arrive faster than event handling?
Locks/Mutex: is housekeeping getting CPU time [phone booth rule, give
priority to leaving]?


-- 
  T o mM i t c h e l l ( o n   N i f t y E g g )

-- 
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/CAAMy4UQWV1Gt9UZBpjpAx01mhL5HEr8NCtGX1rnr1Hevui1Eiw%40mail.gmail.com.

Re: [go-nuts] keep just 2 decimal places in a float64

[Tom Mitchell]

On Sat, Feb 22, 2020 at 1:06 PM 'simon place' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> are you sure?
>
> surely floats can have, say, a small number added, that depending of the
> value, sometimes doesn't change them and sometimes does. seems to me the
> same issue.
>
> On Saturday, 22 February 2020 19:58:09 UTC, robert engels wrote:
>>
>> float equality is useful for determining if “something changed”
>>
>
Yes floats have operation limitations especially when the dynamic range of
a data set (scale) is large and mixed.  Mix large and small floats and try
simple operations like addition.  The random list will have one value, sort
up and down to find two different answers.  Parallel computations with 1,
2, 3many processors will have different net results depending on data
in each block.

Printing converts float to string is not exact.  Truncating the string for
display does not truncate the stored float. Comparing strings is not a
comparison of the floating point data.

Compilers can make transformations and depending on hardware 80 internal
bits for computations all in float registers can mismatch computations that
spill in and out of registers or memory. Some 32 bit computation is done in
64 bit hardware and micro code extracts the 32 bit  value to store in
memory, most  external data data representation (xdr) works but pay
attention.

80 bit floating point hardware is clever but has pitfalls.  Especially with
calling conventions.

-- 
Tinny keyboard.. Mobile ... I am

-- 
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/CAAMy4URsz-7AvLdcNO7HNOv_S-VSCRV3mRn9qFewG9SKWMq-kA%40mail.gmail.com.

Re: [go-nuts] prevent alteration of binaries once distributed in the wild?

[Tom Mitchell]

On Tue, Jul 23, 2019 at 11:51 AM clement auger 
wrote:

> Hi,
>
> I m looking for a technique to prevent binary alteration once distributed
> in the wild.
>
> I have no clue what i m asking for.
>

The best current solutions are package manager oriented.
Decide on the platform you want to work on then look at the package manager
tools.   As well as the access control and audit tools on the platform so
it is installed
in a safe and secure way.

Today most systems have the option of installing mandatory access control
system services.

Some package managers have verify and repair options that can give someone
a warm fuzzy.

Start with keeping a log of the cryptographic quality check sum and other
metadata for your program.  An example: I can download a golang package
and verify that the checksum is as expected before installing.  This is
valuable when the fastest
download is a mirror and the primary metadata is on a far or  slow primary
distribution
machine.

Each platform will have different features.

-- 
  T o mM i t c h e l l ( o n   N i f t y E g g )

-- 
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/CAAMy4URxAx2C60qRucBiRpiLrYOtU0%2BZ4mO7vnyy9boNBQGcnA%40mail.gmail.com.

Re: [go-nuts] OOM occurring with a small heap

[Tom Mitchell]

On Mon, Jul 1, 2019 at 12:42 PM 'Yunchi Luo' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Hello, I'd like to solicit some help with a weird GC issue we are seeing.
>
> I'm trying to debug OOM on a service we are running in k8s. The service is
> just a CRUD server hitting a database (DynamoDB). Each replica serves about
> 300 qps of traffic. There are no memory leaks. On occasion (seemingly
> correlated to small latency spikes on the backend), the service would OOM.
> This is surprising because it has a circuit breaker that drops requests
> after 200 concurrent connections that has never trips, and goroutine
> profiles confirm that there are nowhere 200 active goroutines.
>

Just curious about the network connections.
Is there a chance that the network connections are not getting closed and
cleaned up for some reason.
It was common for sockets to hang around in the thousands because user was
killing a slow tab or the browser
and the full socket close never completed.The solution was  to allow
reliable connections to time out and finish closing
freeing up the memory.   The application has closed the socket but the
protocol has yet to get the last packet to complete the
handshake.  The shell equivalent would be zombe processes that still need
to return the exit status but no process waits
on the status.   Debugging can be interesting in the shell case because of
implied waits done by ps.

How many connections does the the system kernel think there are and what
state are they are in.
Look both locally and on the DB machine.
The latency spikes can be a cause or a symptom.
Look at the connections being made to the CRUD server and make sure they
are being setup with short enough timers
that they clean themselves up quickly enough.   Is the CRUD server at risk
of a denial of service or random curious probe burst
from a nmap script.  Even firewall drops near or far can leave connections
hanging in an incomplete state when an invalid connection
is detected and blocked and long timer reliable network connections are
involved.

-- 
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/CAAMy4UTgoxygmb5UE%2BtUhDgdkS--VmtbT5U8kF0aXQgwXPwA0w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: godoc memory leak

[Tom Mitchell]

Thanks!

On Thu, Jun 20, 2019 at 11:23 AM Christopher Dang <
christopher.d...@wework.com> wrote:

> When I ran the godoc service in a docker image with less memory (6 GiB)
> the behavior was the same. For both a 8 GiB and 6 GiB machine, the godoc
> process continue to consume memory until it surpasses the memory on the
> machine and crashes. After the crash, the other processes on my machine
> continue to work and the memory is freed back entirely to the machine.
>
> On Thu, Jun 20, 2019 at 11:10 AM Tom Mitchell  wrote:
>
>>
>> On Mon, Jun 17, 2019 at 9:40 PM Agniva De Sarker <
>> agniva.quicksil...@gmail.com> wrote:
>>
>>> Couple of questions:
>>>
>>> 1. What version of godoc and Go are you using ? What is your go env ?
>>>
>>>> One other question ...
>> If the OS supports limits does godoc fail nicely with smaller limits.
>> I am reminded of student code that would malloc(to-infinity-and-beyond)
>> because
>> student accounts had user limits and often began with a malloc() loop to
>> get
>> the largest amount possible to ease programming and speed things up.
>>
>>
>>
>> --
>>T o mM i t c h e l l
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/nU706aM7QpM/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/CAAMy4UT4EUDviAgcw0is2fsXzUfp1Xvjc5cPW-_UThkxivdEDg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CAAMy4UT4EUDviAgcw0is2fsXzUfp1Xvjc5cPW-_UThkxivdEDg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
   T o mM i t c h e l l

-- 
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/CAAMy4UR8%2B-1NJ9kyaHegGgN_%2Bg1JW8B-cswgae1aBB%2BpZwz-iQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: godoc memory leak

[Tom Mitchell]

On Mon, Jun 17, 2019 at 9:40 PM Agniva De Sarker <
agniva.quicksil...@gmail.com> wrote:

> Couple of questions:
>
> 1. What version of godoc and Go are you using ? What is your go env ?
>
>> One other question ...
If the OS supports limits does godoc fail nicely with smaller limits.
I am reminded of student code that would malloc(to-infinity-and-beyond)
because
student accounts had user limits and often began with a malloc() loop to
get
the largest amount possible to ease programming and speed things up.



-- 
   T o mM i t c h e l l

-- 
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/CAAMy4UT4EUDviAgcw0is2fsXzUfp1Xvjc5cPW-_UThkxivdEDg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Cross-Compile Windows 10 -> FreeBSD

[Tom Mitchell]

Try a VMWARE virtual machine.
Install a FreeBSD distro and as long as the hardware (CPU) is the same you
should be good.
Even targeting a different hardware platform might be easier inside a VM.

Inside the VM you can save temp files and capture compiler, assembler and
linker settings to
Chip away at it all. ABI, API, Libraries, magic numbers.. paths.
https://www.freebsd.org/doc/handbook/linuxemu-advanced.html
ABI and API updates are difficult.
https://www.cyberciti.biz/open-source/freebsd-12-released-here-is-how-to-upgrade-freebsd/

Look with care (including with a debugger) to see what FreeBSD thinks the
new binary is.
Simple things like CR/LF can confuse things.

I see in a FreeBSD (11.2)  to newer FreeBSD (12.0) version update notes.

Installed packages to be REINSTALLED:
sudo-1.8.25p1 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')
sqlite3-3.25.1 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')
readline-7.0.3_1 (ABI changed: 'freebsd:11:x86:64' -> 
'freebsd:12:x86:64')


Strip nothing,
Minimum optimizations.



On Tue, Jun 11, 2019 at 6:07 PM B Carr  wrote:

> Newb here. I'm in over my head. Using a Win10/amd64 PowerShell with Go
> v1.12.6. Trying to cross-compile
> to FreeBSD/amd64. go env = GOARCH=amd64 & GOOS=freebsd. Source includes
> calls to SQLite3. Compiles
> without errors.
>
> Resulting binary fails on FreeBSD with: "Can't connect to the SQLite DB
> Binary was compiled with 'CGO_ENABLED=0', go-sqlite3 requires cgo to work."
>
> Added CGO_ENABLED=1 to the go env.  Recompile fails to build a binary and
> yields this error stream:
>
> "# runtime/cgo
> _cgo_export.c:1:0: error: -fPIC ignored for target (all code is position
> independent) [-Werror]
>  /* Code generated by cmd/cgo; DO NOT EDIT. */
>  ^
> cc1.exe: all warnings being treated as errors"
>
> I have no idea what that means.
>
> Same source compiled for the Win10 machine runs perfectly. If I copy the
> source code over to a
> FreeBSD box with Go installed there and compile, it works fine. It is the
> cross-compilation that
> doesn't seem to work.
>
> This isn't a Go problem, it is something I'm not understanding about
> cross-compiling
>
> Any thoughts?
>
> --
> 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/ebe9fe0d-7727-40b9-bc53-a9d237faecf7%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
   T o mM i t c h e l l

-- 
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/CAAMy4URXSgtj55VTNcRUagX4PAx4s30uT5coxuoJpFBS9t9FKA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

[Tom Mitchell]

This makes a bit of sense from the Google point of view.

The central nut of a language under development is something that needs to
be well managed.
I have seen this with Modula-2 in the past as well as C++.
Niklaus Wirth declined blessing a standard library for Modula-2 perhaps
killing it as a market and
SGI an early adopter of C++ ended up with many man years of C++ library
code that no longer
compiled and run with a spin of the C++ revision dial outside of their
control.

>From the system design view the layers of code dare not look like
spaghetti.
At SGI a number of GFX libraries had symbols that allowed the entry to
the black box internals of important GFX functions.  Improvements or
changes to
the internals of these black box functions for many reasons including new
hardware
broke a lot of internal and external code (internal symbols were stripped
after this)

Hardware vendors have to protect their unimplemented instruction space.
Language designers need to managed the central nut of the language.
TeX has bounds  and a test suite if  your code is to be called TeX it must
pass
the test and all that.

Building code that runs reliably requires discipline and by way of
example is the constrained languages used by Knuth used to code TeX
(WEB).  And N.B.  that LaTeX is not part of TeX but is written in TeX.









On Thu, May 23, 2019 at 6:18 AM  wrote:

> https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGooglesLanguage
>
> --
> 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/ac6843c0-38fc-4388-a1dd-2dd2b78c0ac3%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
   T o mM i t c h e l l

-- 
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/CAAMy4URk2teSF6x3Uqd-ABcZ-FWU-To8mCQzEKZZejtuJVRhYg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: built-in alternative to bcrypt?

[Tom Mitchell]

On Mon, Apr 22, 2019 at 1:18 PM whitehexagon via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Thanks everyone, plenty more reading for me!
>


> The argon2 looks interesting, but it sounds like it could be very memory
> heavy.  The code I'm porting is running on a PAAS/SAAS setup, and that
> might have cost implications exceeding the worth of my low value data.
>

Try to not judge the value of your data as being low.
Store only hashed and salted passwords and data.
Passwords in the clear or stored in a lame or fragile manner is something
that gets negative and snarky press world wide.
Data at rest should be safe.
Revisions to update to a better solution might be hampered if you start out
thinking your data is low value and
success happens.

The size of a go program is likely darn close to the netsum memory
footprint of a C program and the resident set size
might be smaller with go.

Plan ahead.


-- 
   T o mM i t c h e l l

-- 
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] why is this not ascending?

[Tom Mitchell]

On Mon, Apr 8, 2019 at 10:15 AM T L  wrote:

> time.Sleep is not a synchronization method.
> time.Sleep(dt) means pausing the execution of the current goroutine for at
> least dt duration.
> The actual paused duration may be longer than dt.
>

Not only is sleep not a synchronization method but I/O need only grab the
data and
queue some work to push it out later. Look at the I/O you are using in more
depth.
"Go has a scheduler that lets you write synchronous code, and does context
switching on its own and
uses async IO under the hood." (
https://stackoverflow.com/questions/36112445/golang-blocking-and-non-blocking
).
Summary look under the I/O hood too.

-- 
   T o mM i t c h e l l

-- 
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] [CoC] screenshot images. Lazines or incompetence?

[Tom Mitchell]

On Mon, Mar 11, 2019 at 3:17 AM Wojciech S. Czarnecki 
wrote:

> There is an emerging issue with screenshots of logs or code
> being posted
>
...

> I also urge anyone who gives their time to look at the posted picture,
> just because they can see, and who want to help a screenshot's OP
> to demand from her or him that she or he will take her time to repost
> her answer this time with errs/code in textual form.
>

It is wasteful of bandwidth and storage.
It is also a risk... perhaps enough to disallow.
Image format decoding is not sufficiently safe to be enabled blindly
on my mail reader.   Images and URIs can be the vector of viruses and
malware.

https://tools.cisco.com/security/center/viewAlert.x?alertId=52257
"Summary
"A vulnerability in Adobe Flash Player could allow an unauthenticated,
remote attacker to execute arbitrary code.
"The vulnerability is due to improper handling of regular expressions by
the affected software. An attacker could exploit this vulnerability by
persuading a user to open a malicious web page that contains crafted Flash
content. A successful exploit could trigger a stack-based buffer overflow
condition in the RegExp class for specific search strategies, which the
attacker could use to execute arbitrary code in the context of the current
process.
"Adobe has confirmed the vulnerability in a security bulletin and released
software updates."


-- 
   T o mM i t c h e l l

-- 
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] What does a deadlock mean in golang?

[Tom Mitchell]

On Tue, Jan 29, 2019 at 12:55 AM 伊藤和也  wrote:

> I know the general meaning of a deadlock, but I don't know the meaning of
> a deadlock in golang.
>

Good question...
A classic and now hard to find reference for a deadlock is "Operating
System Principles (Prentice-Hall Series in Automatic Computation) by Per
Brinch Hansen"


> For example, I send 4 values to a buffered channel whose maxmum size is 3
> and a deadlock occurs.
>

Yours is blocking I/O and not a programming error with semaphores,
monitors  and mutual exclusion
of your own design.

Since the internals of Go detect this it seems correct but the run time
detection would not reach out to
other machines in the case of channel I/O abstracted to and on a  far away
resource.  The message
in all no progress cases likely should have a unique error.  If an event
could unblock this then the presence
of an event handler is or is not checked.  Timers... ?

Interesting.




-- 
   T o mM i t c h e l l

-- 
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] if/switch statements as expressions

[Tom Mitchell]

On Thu, Dec 20, 2018 at 2:48 PM Michael Jones 
wrote:

> interesting! i wish algol 68 had had its chance.
>

Well, "It ain't over till it is over."

http://algol68.sourceforge.net/

" multiple licenses that should be read carefully: it is open source
software, but not all components are fully free"






>
> On Thu, Dec 20, 2018 at 2:40 PM Bakul Shah  wrote:
>
>> On Thu, 20 Dec 2018 13:13:04 -0800 Michael Jones 
>> wrote:
>> >
>
> ...

>
>> Algol-68 allowed this by design. No hack required! The value
>> of a sequence of expressions was the last expression. It also
>>
>

-- 
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 offline development recommendations

[Tom Mitchell]

On Wed, Dec 12, 2018 at 10:15 PM snmed  wrote:

> Thank you very much for your reply. It seems to be a possible way to do
> it, what do you think about the athens way? In my point of view it would be
> the easiest way as far i can preload the athens cache with all the required
> packages,
> And then the only thing a developer has to do, is to set the GOPROXY to
> the athens instance.
>


> Such setups are supported by the Go from its onset.
>>
>> 1. DMZ box where `go get` can reach external repositories
>> 2. IDP internal distribution point - with vetted go tools and vetted libs
>>
>

The methods in athens seem to be a good starting point.   The challenge is
the vetting when a big
resource like this has a lot of changes often quickly.

Be sure to anchor yourself in a strategy that can scale.
I can see success spawning multiple projects that cannot see each other
multiplying
permutations.   A DMZ box is not an air gap but might be necessary as a
first  step in
protect the transfer and stage the process before anything crosses the air
gap.

It sounds like a project ... it does sound as if you understand the
challenges.
You will depend on Athens so that needs to be tracked as well.
Sounds like fun.






-- 
   T o mM i t c h e l l

-- 
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 offline development recommendations

[Tom Mitchell]

On Wed, Dec 12, 2018 at 12:00 PM snmed  wrote:

> Hi all
>
> Our customer demands an offline development environment with no internet
> connection, is there any best practices to handle package download and
> project setup for such an use case? And how would the new go modules fit in
> in such an environment?
>
> Any advise will be most appreciated.
>

Such a requirement can only be addressed with an air gap bridge.
Are they working with Linux or another platform?

On linux  it is easy to "touch /var/tmp/now"  and "find / -newer
/var/tmp/now"
and collect anything that is pulled in locally.  then burn selected  bits
to a CDROM.

Users inside the offline isolation booth have to make requests for library
and module
source or binaries and communicate possibly with paper for the bits they
need.
Dummy, stub programs will make it easy to identify and trigger the
downloads of objects.
No USB sticks...

The CDROM set is an audit trail and allows virus scanning.

The same is true for any and all system services libraries and more inside
the development environment.
That off line development  environment likely needs exactly the same or
stricter audit and reproducible setup.
At each release cycle and checkpoint for debugging ... so leverage that
same audit and management
systematic process.

Their ask is bigger than golang.







-- 
   T o mM i t c h e l l

-- 
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 (binary or text) File transfers over rpc

[Tom Mitchell]

Moving files is a solved, non trivial problem 
Have you looked at tools like scp (ssh), rsync, kermit, ftp, sftp, tftp and
network filesystems (nfs and samba)?
Even git and http.  Error recover, host name lookup, compression, restart,
safe abort, transport encryption, authentication, buffering.

https://en.wikipedia.org/wiki/Sorcerer%27s_Apprentice_Syndrome
https://stackoverflow.com/questions/68335/how-to-copy-a-file-to-a-remote-server-in-python-using-scp-or-ssh





On Thu, Nov 1, 2018 at 11:24 PM Tamás Gulácsi  wrote:

> 2018. november 2., péntek 6:21:47 UTC+1 időpontban Anirudh Vyas a
> következőt írta:
>>
>> Hello there -
>>
>> I am looking for example/help for using rpc to do file downloads - I am
>> not sure if this is possible, or recommended or if there is a
>> better/cleaner way. I like the robust nature of RPCs and have written a few
>> good, performant distributed systems in them - was hoping/wondering if I
>> could use RPC to do downloads - I currently use combination of io.Copy and
>> a TCP server to do this.
>>
>
> What kind of RPC ? RPC is just "Remote Procedure Call".
> If s `send(data []byte)` won't be enough (size restrictions), you can copy
> the io interfaces:
> CreateFile(name, perms...) (fileHandle)
> WriteFile(fileHandle, chunk)
> CloseFile(fileHandle)
>
>
> --
> 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.
>


-- 
   T o mM i t c h e l l

-- 
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 += Package Versioning

[Tom Mitchell]

On Tue, Feb 20, 2018 at 2:29 PM, Bakul Shah  wrote:

> On Tue, 20 Feb 2018 13:02:47 -0800 David Anderson 
> wrote:
> >
> > As a counterpoint to this: with vgo, I plan to make all my binary modules
> > specify that they want the latest versions of everything,
>
.

>
> The right choice here is not clear (at least to me).
>
.

>
> Usually more stable versions are tagged and "released"
>

My bias is to use the latest "released" tools libraries and source.
Released code has more interactions and probably a better chance
for the community discovery of an issue you care about.

Build and test often as part of the process.

It is not just the libraries but also the compiler and build system itself.

I spent a month+ trying to sort out a customers application bug that
resulted from promotion of an optimization to an intrinsic in a compiler
update.

Compilers and applications can be victims of a system lib change and more
including system test
resources.

This is a difficult problem and the answer involves knowing (best guess)
what it takes to debug the
entire pile of worms not just the application.  It is turtles all the way
down but one
possible solution is to put all the worms you can in a virtual machine that
can be canned and archived.
A 4.7 GB DVD or a 25 GB Blu-Ray archival quality disk for the self
contained
single purpose built VM.   A 25GB system is worthy for a lot of projects
but not all.


-- 
  T o mM i t c h e l l

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