profile
viewpoint
Giovanni Bajo rasky Develer S.r.l. Florence, Italy http://giovanni.bajo.it Developer Relation @italia / @teamdigitale. CTO of @develersrl and @greenapes; Python, Go, C++. Interested in algorithms & security.

rasky/gcs 86

Golomb Coded Sets

rasky/geventconnpool 78

Generic TCP connection pool for gevent-based applications

rasky/genemu 22

Basic Genesis / MegaDrive Emulator

rasky/CryptoFaxPA 6

CryptoFaxPA

rasky/g64drive 6

Portable Linux/Mac tool for Retroactive 64drive

rasky/dnsmasq-dnssec 4

Implementation of a DNSSEC resolver in dnsmasq (WIP)

AdRoll/baker 2

Baker is a high performance, composable and extendable data-processing pipeline for the big data era

rasky/freemyfeed 2

Use password-protected URLs for feeds in Google Reader

rasky/develhack 1

DevelHack 2016 entry

DevelBoard/barebox 0

Barebox fork for DevelBoard – http://www.barebox.org

issue commentgolang/go

proposal: os: make Readdir return lazy FileInfo implementations

I'd strongly prefer -1 rather than 0. We could also define a special modebit for "stale FileInfo".

I'll be on record to say this is a horrible idea as well. It's not clear why we are designing a new FS abstraction and inheriting what is clearly a mistake of the past. The only reason I see is that this is rushed to have embed.Files in 1.16, and this lazy FileInfo is probably the only solution not to miss the 1.16 deadline. I'm not sure it's a good idea.

rsc

comment created time in 17 days

issue commentgolang/go

crypto/x509: make SystemCertPool work on Windows?

If a thin wrapper around syscall.CertOpenSystemStore is added for Windows then that changes and it does become a nuanced API, because it'll do one thing one most systems and another very, very different thing on Windows.

Can you please clarify this? How the snippet in https://github.com/golang/go/issues/16736#issuecomment-540373689 is doing something very very different compared to what happens on other operating systems?

bradfitz

comment created time in 20 days

issue commentGekkio/imgui-rs

Docking?

Notice that a port of the docking branch already exists: https://github.com/Gekkio/imgui-rs/pull/285

It works (I'm using it). It's using the docking branch from January 2020, I can update it if somebody wants to use a newer one.

cheako

comment created time in 20 days

PR opened immuni-app/immuni-app-android

Cambia gli inglesismi "persona COVID-19 positivo"

All'interno della app, viene usata più volte la locuzione "persona / utente COVID-19 positiva" che non mi sembra corretto in lingua italiana. Si tratta probabilmente di un inglesismo.

In questa PR, ho modificato tutte le occorrenza uniformando il riferimento da "utente" a "persona", e cambiando la locuzione in "persona positiva/negativa al COVID-19".

NOTA: Non ho testato questa modifica perché non sono uno sviluppatore Android. È una semplice modifica ai testi che non ne modifica in modo importante la lunghezza, quindi non mi aspetto problemi, ma voi saprete testarla sicuramente in modo opportuno.

+8 -8

0 comment

1 changed file

pr created time in a month

push eventrasky/immuni-app-android

Giovanni Bajo

commit sha 6f360ab0d51b847bdaf47a93b9b627eaacd1c37f

Cambia gli inglesismi "persona COVID-19 positivo" All'interno della app, viene usata più volte la locuzione "persona / utente COVID-19 positiva" che non mi sembra corretto in lingua italiana. Si tratta probabilmente di un inglesismo. In questa PR, ho modificato tutte le occorrenza uniformando il riferimento da "utente" a "persona", e cambiando la locuzione in "persona positiva/negativa al COVID-19".

view details

push time in a month

fork rasky/immuni-app-android

Official repository for the Android version of the immuni application

fork in a month

issue commentgolang/go

proposal: cmd/go: notify about newer major versions

It simply isn't true that publishing a new major version of your software that isn't API compatible with older major versions "breaks users". The definition of "break" which allows that sentence to be true is so broad that it loses meaning.

Then let's choose a different term. Publishing a new major version, without also maintaining ongoing support for existing major versions, drops support for existing users. And if those users want to stay on supported versions of their dependencies, they must make essentially the same manual changes that they would need to make for a breaking API change.

I gave a look at go-github Release Page. The now-current latest release is v32.1.0 which does some non-breaking changes like adding the new field twitter_username to the User object. They did this fix only in the v32 major version, and they did not bother to backport this change to all the previous 31 major versions, releasing minor versions for all of them. If I am on any major version which is not v32, I'm unable to access the twitter_username field in the User object. I manually patched v3.0.0 to add TwitterUsername to User and guess what, it works. So there's no real technical reason why that change was not applied to all 33 major versions rather that just the last one, if not an explicit maintainer choice of not supporting previous major versions. So I think we can agree that go-github maintainers only support the latest major version and drops support for all previous major version as soon as a new one is released (multiple times per year).

If I were a user of that library, I would be forced to upgrade to v32 to access this new field, which in turns breaks my code. This is what Russ also mentioned: he needed to access a new GitHub API and was forced to upgrade go-github major version which in turns broke his code. The same would apply if we were discussing a bug-fix instead of a new feature: since the previous major versions are not maintained, having the bugfix would require me to upgrade to the last major version (or at least one new enough to contain the bugfix), breaking my code in the process.

Everything the maintainers are doing is technically well-defined and they correctly reported what they did through semantic versioning. On the other hand, I would say their behavior is hostile to users of their library, and I would be very sad if this became common in the Go community. I would never be willing of being a user of a library which requires me to upgrade to API-incompatible major versions (and thus break my code) multiple times a year to access new features and new bugfixes.

So in the end, I think this proposal boils down to this:

  • Scenario A: If you feel like it's normal and acceptable that a library maintainer releases a new major version multiple times a year, while dropping support for previous major versions at the same time, then I think this proposal makes sense because users must be aware as early as possible that they need to upgrade to a major version, so that they can plan accordingly to adjust their code for the API-incompatible changes that the library decided to do (rather than finding out when they're in the rush of fixing something and find out that they also need to upgrade the major version of a dependency to get their work done).
  • Scenario B: If you instead feel that it's normal for a library to stay on a major version for a long time (eg: years) and possibly after a v2 is eventually released, maintain v1 for even more years to help the users, then this proposal should be rejected, because it adds a console message that is not immediately actionable and is probably even against the wills of the library maintainers. It would be much better to let the maintainer add a deprecation notice to specific unsupported major versions when they eventually drops support of them (like another proposal is already discussing).

Since I'm in team B, my vote is to reject this proposal. Accepting this proposal would be an implicit hint that scenario A is acceptable and supported, if not even encouraged.

zachgersh

comment created time in a month

issue commentgolang/go

proposal: cmd/go: default to & improve -mod=readonly

That was #32027. Before that, pretty much everything required several network fetches, so builds were slow and non-reproducible. We felt it wasn't a good user experience, especially for new users.

Thanks for the pointer, I had missed that discussion. I'm not really happy about the outcome but such is life.

rsc

comment created time in a month

push eventdevelersrl/showtime2

Apruzzese Francesco

commit sha 73d03a7df843b1c520691b4a0e01166d32bc351d

[FIX] Show only timesheets linked to billable tasks (#10)

view details

push time in a month

PR merged develersrl/showtime2

[FIX] Show only timesheets linked to billable tasks

RICHIESTA

Dopo aver messo questo link (link generato da showtime ndt), NON devono essere mostrati i TS legati a TASK NON BILLABLE

+1 -8

1 comment

1 changed file

OpenCode

pr closed time in a month

issue commentgolang/go

proposal: cmd/go: notify about newer major versions

@peterbourgon my two cent is that semantic versioning should not be used as an excuse to break user code.

If you as a maintainer break your clients 32 times in a few years because you feel that it's safe to do it thanks to semantic versioning, then I don't want to be your user because you are not a maintainer who values stability and consistency; you're probably too much concerned about playing with your own library and doing refactorings for your own sake rather than providing a value to somebody else. That's ok, but I don't want to depend on your playground.

In fact, I was against introducing semantic versioning in Go modules: I felt the risk of the community shifting to a break-often model would have been too high. In my opinion it would have been enough to let a library simply fork to a new URL when they absolutely needed to break compatibility, once every few years. In fact, on the other hand, the absence of semantic versioning discourages library authors from breaking APIs, which is a very good thing in my opinion. Go itself (all its standard library and builtins) has been preserving v1 compatibility for more than 10 years, I don't see how a library wrapping GitHub API feels entitled to break their users 32 times. The only answer to that is that they think it's "normal" to do it "because semantic versioning allows me to do it". That's a bug, not a feature, in my opinion.

From your other comments in this issue, it seems like you feel it's perfectly acceptable to break an API because semantic versioning allows you to do it. I don't want to misrepresent your thoughts, this is just what I got. I guess we live in different worlds with different drivers, and I think this is the difference you're probably not appreciating.

zachgersh

comment created time in a month

issue commentgolang/go

proposal: cmd/go: default to & improve -mod=readonly

Actually, running go run <MODULE> is a very good way to have people running CLI tools written in Go. Would that be broken by this proposal for people running in this command in a folder where go.mod doesn't even exist?

rsc

comment created time in a month

issue commentgolang/go

gerrit: add new Trust+2 label requirement for code reviews

Who will be allowed to add a Trust+1? Is that the same ACL of CodeReview+2, or is it a different one?

What would be the suggested policy for reviewers about when to add Trust+1, and how is that different from the current practice of adding CodeReview+1 when you have reviewed the code, think the code is correct but you don't feel knowledgable enough to approve it?

rsc

comment created time in a month

push eventdevelersrl/showtime2

Francesco Apruzzese

commit sha 5769ae9c879ca6191983a698491110df159690a8

[IMP] New logo

view details

Giovanni Bajo

commit sha 18dc589874b769eef428acb82cd2774a188e8f75

Merge pull request #9 from openforceit/new_logo [IMP] New logo

view details

push time in 2 months

PR merged develersrl/showtime2

[IMP] New logo
+0 -0

1 comment

1 changed file

OpenCode

pr closed time in 2 months

pull request commentdevelersrl/showtime2

[IMP] New logo

Lo mergio, ma andrebbe cambiato anche il CSS per seguire il nuovo set colori.

OpenCode

comment created time in 2 months

issue commentgolang/go

proposal: runtime/pprof: add PMU-based profiles

@chabbimilind I’m not in the review committee but both Russ and Ian have stated that the proposal would be easy to accept if it had zero API and not too much code. I think it’s pretty clear that if you modify the proposal to reflect the zero API, the proposal would be accepted. I’d be glad if you did it.

chabbimilind

comment created time in 2 months

issue commentgolang/go

proposal: runtime/pprof: add PMU-based profiles

If you have a scenario where you absolutely need to be sure that PMU is used (and prefer the process to quit if it's not possible), you can use something like GODEBUG=pprof_backend=pmu, and the runtime could abort the process if it detects that PMU is not supported. The default of that variable would be GODEBUG=pprof_backend=auto, meaning "automatically select the best available backend on my system".

chabbimilind

comment created time in 2 months

issue commentgolang/go

proposal: runtime/pprof: add PMU-based profiles

@chabbimilind thanks for your proposal and implementation. I'm excited to see this landing.

I don't understand why you think that a first version of the proposal cannot be landed with zero new API. The proposal doesn't explicitly state why (or I couldn't find a place where it does). It seems that the idea behind introducing the new API is to expose the full functionality of PMUs (eg: cache misses). If you drop that from the proposal (and leave it to a second iteration), it should well be possible to use the existing pprof API, and transparently use PMUs only on supported architectures. That would provide a real benefit for many users as-is, as far as I can tell.

In a previous comment, you say:

I cannot see how zero API change is possible. We need to maintain the OS interval timer as the default sampling engine to work across all platforms under all environments. The hardware performance counter-based sampling engine has to enabled by exposing at least one API.

I don't understand this point. I reckon you can keep the default sampling engine as a default for all architectures, and also use PMUs when they are supported (eg: Linux/x86). Is it technically impossible to keep both code paths in the runtime, and select the correct one at either compile-time or run-time? If so, why?

chabbimilind

comment created time in 2 months

startedanimetosho/jit_smc_test

started time in 3 months

push eventdevelersrl/showtime2

Francesco Apruzzese

commit sha 0d92721c63e6431dff42c69c27314cdac3c10400

[FIX] Enable URL shortener

view details

Francesco Apruzzese

commit sha 838e8b57f09e8b306f772624b0433c77850619d9

[FIX] Show timesheet before 2020

view details

Giovanni Bajo

commit sha 02f17dddab6aa0d539fb97edba40e42b288ebd44

Merge pull request #8 from openforceit/fix_sugg_bajo Fix URL shortener and timesheet beore 2020

view details

push time in 3 months

Pull request review commentdevelersrl/showtime2

Fix URL shortener and timesheet beore 2020

 def hours(self, client, projectids, from_date=None, to_date=None):             ('project_id', 'in', projectids),             ('date', '>=', from_date.strftime('%Y-%m-%d')),             ('date', '<', to_date.strftime('%Y-%m-%d')),+            '|',             ('timesheet_invoice_type', '!=', 'non_billable_project'),+            ('timesheet_invoice_type', '=', False),

Please leave a comment here describing which part is required for pre-2020, and which is valid for the future.

OpenCode

comment created time in 3 months

more