Thanks Sebastien, I'll check it out.
On Tue, Jul 7, 2020 at 8:52 PM Sebastien Binet wrote:
> hi,
>
> wrt Modbus, I have been using that library for the slow control of the
> LSST telescope testbench[1]:
> - github.com/goburrow/modbus
>
>
>
> pretty robust.
>
> [1]:
Worked for me, Thanks!
On Thursday, January 7, 2016 at 3:51:12 PM UTC+5:30, Tamás Gulácsi wrote:
>
> Add keys - for
> type s struct{a,b int}
> Instead of z :=s{1,2}
> Use z :=s{a:1,b:2}
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To
On Wed, Jul 8, 2020 at 2:44 AM 'Jacob Kopczynski' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> I tried to state a path relative to the home directory, since in the
> context I am writing for the path from ~ to the Git repository will be
> consistent, though the meaning of ~ may change
You can do this:
home, _ := os.UserHomeDir()
absPath := home + "/trunk/infra/metadata/config.cfg"
> On Jul 7, 2020, at 4:32 PM, 'Jacob Kopczynski' via golang-nuts
> wrote:
>
> I tried to state a path relative to the home directory, since in the context
> I am writing for the
On Tue, Jul 7, 2020 at 4:44 PM 'Jacob Kopczynski' via golang-nuts
wrote:
>
> What's the process for submitting a change to a core library like this one?
> Ideally, to the code, but I'd settle for making the documentation clearer.
Sorry, I didn't answer this question. For changes that don't
On Tue, Jul 7, 2020 at 5:44 PM 'Jacob Kopczynski' via golang-nuts
wrote:
>
> I tried to state a path relative to the home directory, since in the context
> I am writing for the path from ~ to the Git repository will be consistent,
> though the meaning of ~ may change based on user. A snippet:
>
On Tue, Jul 7, 2020 at 4:44 PM 'Jacob Kopczynski' via golang-nuts
wrote:
>
> I tried to state a path relative to the home directory, since in the context
> I am writing for the path from ~ to the Git repository will be consistent,
> though the meaning of ~ may change based on user. A snippet:
>
The ~ is a feature of the OS shell.
> On Jul 7, 2020, at 6:44 PM, 'Jacob Kopczynski' via golang-nuts
> wrote:
>
> I tried to state a path relative to the home directory, since in the context
> I am writing for the path from ~ to the Git repository will be consistent,
> though the meaning
I tried to state a path relative to the home directory, since in the
context I am writing for the path from ~ to the Git repository will be
consistent, though the meaning of ~ may change based on user. A snippet:
const specPath = "~/trunk/infra/metadata/config.cfg"
absPath, _ :=
On Tue, Jul 7, 2020 at 10:44 AM, roger peppe wrote:
>
> In my description, there's no assumption that doing it over the type
> parameter implies a refinement of the previously set type constraints. In
> fact it definitely implies otherwise because (for example) if you know that
> a generic type
Hello!
I would like to share my use for generics, as there have been a public
callout for feedback:
> Second, we know that many people have said that Go needs generics, but we
> don’t necessarily know exactly what that means. Does this draft design
> address the problem in a useful way? If
On Tue, 7 Jul 2020 at 21:05, Tobias Gustafsson <
tobias.l.gustafs...@gmail.com> wrote:
> Den tisdag 7 juli 2020 kl. 16:45:21 UTC+2 skrev rog:
>>
>> On Tue, 7 Jul 2020 at 10:36, Tobias Gustafsson
>> wrote:
>>
>>> Hi all,
>>>
>>> Thanks for the response on this subject!
>>>
>>> Yes, a kind of type
Den tisdag 7 juli 2020 kl. 16:45:21 UTC+2 skrev rog:
>
> On Tue, 7 Jul 2020 at 10:36, Tobias Gustafsson > wrote:
>
>> Hi all,
>>
>> Thanks for the response on this subject!
>>
>> Yes, a kind of type switch over generic types is probably what I
>> envision. There is a potentially nice symmetry
hi,
wrt Modbus, I have been using that library for the slow control of the LSST
telescope testbench[1]:
- github.com/goburrow/modbus
pretty robust.
[1]: https://github.com/go-lsst/fcs-lpc-motor-ctl
‐‐‐ Original Message ‐‐‐
On Tuesday, July 7, 2020 10:35 AM, Erman Imer wrote:
>
On Tue, Jul 7, 2020 at 2:56 AM Amnon wrote:
> A sensible, well thought out, design.
>
> My main worry is that we will come unstack in places that are using
> versions of the Go toolchain older than N-2.
> Is there any reason for them not to upgrade? No
> Should they upgrade? Definitely
> But
Hello,
I am using these libraries to communicate with Siemens S7 and Modbus Tcp
devices in industrial projects.
https://github.com/ermanimer/ict
All comments are wellcome...
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe
> the name "pure" may be debatable, but the characteristic is the same
with "constexpr" in C++, although I also don't have a strong reason why
this is important beside separation IO and non-IO
D is a lange that has true pure functions, see
https://dlang.org/spec/function.html#pure-functions
> go clean -modcache
It seems that the only way is to clean all packages.
Thank you very much!
Ge
在2020年7月7日星期二 UTC+8 下午5:51:17 写道：
> go clean -modcache
>
> On Tuesday, July 7, 2020 at 9:23:50 AM UTC+2 HailangGe wrote:
>
>>
>> Thanks. I'm just trying to look for if there are any way to clean
On Tue, 7 Jul 2020 at 10:36, Tobias Gustafsson <
tobias.l.gustafs...@gmail.com> wrote:
> Hi all,
>
> Thanks for the response on this subject!
>
> Yes, a kind of type switch over generic types is probably what I envision.
> There is a potentially nice symmetry with the current runtime type
The standard math library is a natural, easy gateway; a simple preprocessor
could do it. maybe i'll prototype it.
On Tue, Jul 7, 2020 at 4:43 AM Brian Candler wrote:
> On Tuesday, 7 July 2020 01:46:48 UTC+1, Kurniagusta Dwinto wrote:
>>
>> > i would value "pure" if it were a contract for early
On Tuesday, 7 July 2020 01:46:48 UTC+1, Kurniagusta Dwinto wrote:
>
> > i would value "pure" if it were a contract for early evaluation
> does this "early evaluation" concern about IO? like loading blob data with
> ioutil.ReadFile into global variable at compile time?
>
I think by definition,
go clean -modcache
On Tuesday, July 7, 2020 at 9:23:50 AM UTC+2 HailangGe wrote:
>
> Thanks. I'm just trying to look for if there are any way to clean them in
> a programmer's way.
> 在2020年7月7日星期二 UTC+8 下午1:26:16 写道：
>
>> Just delete them all.
>> Your next build will repopulate the ones that
Hi all,
Thanks for the response on this subject!
Yes, a kind of type switch over generic types is probably what I envision.
There is a potentially nice symmetry with the current runtime type switches
and type annotations that caught my eye (being aware of the fact that
finding false patterns
Thanks. I'm just trying to look for if there are any way to clean them in a
programmer's way.
在2020年7月7日星期二 UTC+8 下午1:26:16 写道：
> Just delete them all.
> Your next build will repopulate the ones that are needed.
>
--
You received this message because you are subscribed to the Google Groups
A sensible, well thought out, design.
My main worry is that we will come unstack in places that are using
versions of the Go toolchain older than N-2.
Is there any reason for them not to upgrade? No
Should they upgrade? Definitely
But some still haven't.
Perhaps we should force them to upgrade
How about something like this?
Type switches
A *generic type switch* allows a generic function to provide specialized
behaviour based on its type arguments (for example to use a more efficient
implementation for some types).
A type switch refines the type of a type parameter. Cases match actual
26 matches
Mail list logo
