Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Mar 07 17:29
    @directhex banned @CharlieIsHere
  • Oct 11 2018 17:23
    @directhex banned @deleteaccount1234567890
Phil Jaenke
@rootwyrm
Probably should but that's definitely a Windows question because Microsoft has their own timezone database (TZdatabase++)
The real problem is that FreeBSD and Linux disagree extensively on valid timezones. i.e. FreeBSD does not have US/Eastern it uses EST5EDT or EST
Calvin Buckley
@NattyNarwhal
$ echo $TZ
<EST>5<EDT>,M3.2.0,M11.1.0
i think this is allowed by POSIX, but software just can't cope
Phil Jaenke
@rootwyrm
TZstandard++
(Sigh.)
Alexander Köplinger
@akoeplinger
hm then we need some freebsd-specific code in the test
Steve Pfister
@steveisok
we're going to need to change up the tests then :disappointed:
Phil Jaenke
@rootwyrm
Anyhow, FreeBSD uses /usr/share/zoneinfo/zone.tabfrom IANA basically
But yeah, definitely need to think on it a bit.. and learn some C# apparently.
Calvin Buckley
@NattyNarwhal
most OSes ship IANA's zoneinfo intact (well, AIX ships it in a weird place, but I placed a symlink on CI,, because it's hardcoded in System)
did anyone say TimeZoneInfo.cs.in :grimacing:
rootwyrm @rootwyrm cowers under a rock. Under a mountain. On the bottom of the ocean.
Nikolay Sivov
@nsivov
@akoeplinger @steveisok another one in my queue that's assigned to you both, mono/mono#16324. It's rather benign, adding attributes, and rearranging methods in compatible way, please let me know if you have any questions
Phil Jaenke
@rootwyrm
I'm going to create a issue for the TZ stuff so it's a bit more clear, I think.
Phil Jaenke
@rootwyrm
Opened mono/mono#16415 for the timezone stuff.
Phil Jaenke
@rootwyrm
@NattyNarwhal I'm gonna break all your stuff 'kay? ;)
Calvin Buckley
@NattyNarwhal
oh no
Phil Jaenke
@rootwyrm
Actually, I kinda hope it won't break anything since 7.1 + uses IANA but it's in a weird location.
Calvin Buckley
@NattyNarwhal
the CI box runs 6.1
it has IANA from BOS though
Phil Jaenke
@rootwyrm
Oh yeah... I keep forgetting about that because I keep actively suppressing my memories of 6.1.
D.S. Qiu
@srxqds
how can I debug using vs with embeded mono, is three any detail introduction?
who can give some advice or some details?
Mikkel Kruse Johnsen
@mikkeljohnsen
@rootwyrm I just compiled the nightly with the patch: #16298 but it has no effect on Process.Start.
This is really a problem that Mono is broken and I'm forced to go back to Mono 4.8, to get it to work.....
Phil Jaenke
@rootwyrm
@akoeplinger there's a lot of pretty ugly hard-coding in TimeZoneInfoTest.cs ... I think this just turned into a 'really fix the test.'
Alexander Köplinger
@akoeplinger
hmm I thought it's just a few cases of deprecated identifiers?
Phil Jaenke
@rootwyrm
On the surface, yes. The problem is there's a lot of hard-coded time zones further down the list.
Alexander Köplinger
@akoeplinger
can you give an example?
Phil Jaenke
@rootwyrm
Yep, was just grabbing a good one. :)
There's a couple just like this...
            public void BrusselsSupportsDST ()
            {
                TimeZoneInfo brussels = TimeZoneInfo.FindSystemTimeZoneById (MapTimeZoneId ("Europe/Brussels"));
                Assert.IsTrue (brussels.SupportsDaylightSavingTime);
            }
So if the Olson database deprecates it in the future, the tests will break again. Because time zones are hell.
Alexander Köplinger
@akoeplinger
sure, but we can fix it once that happens
let's just fix what is broken right now
Phil Jaenke
@rootwyrm
Sounds like a plan.. I do see a sensible way to fix it 'right' but given my lack of C# experience, probably inadvisable in the short term.
Filip Navara
@filipnavara
@EgorBo btw, there is BDN PR for fixing the in-process iterations which were crashing some of the benchmarks. It will likely take few days to propagate it all the way through git, Nugets, etc. before it gets picked up by dotnet/performance..
Egor Bogatov
@EgorBo
great news anyway :smile:
I currently use the default (non inprocess) mode with --llvm jit
Filip Navara
@filipnavara
I gave up on that, it was too slow (but somehow it looks like it improved now)
Egor Bogatov
@EgorBo
the latest results are quite promising
Zoltan Varga
@vargaz
so do we have any benchmark results comparing master to like 2 weeks ago ?
Egor Bogatov
@EgorBo
I'll run some old revision after the current iteration with the same parameters (Release, MONO_THREADS_SUSPEND=preemptive mode, etc)
Filip Navara
@filipnavara
I do have logs on my pipelines but I only tried the
LLVM builds recently so nothing for comparison except regular Mono
(still didn't get to produce nice charts :/)
Filip Navara
@filipnavara
I can run the pipelines on historical Mono builds though, if needed
Zoltan Varga
@vargaz
just want to know whenever the stuff we are doing made any real difference.
Egor Bogatov
@EgorBo
we need jit diff tools :smile: you change something (e.g. add a new pass) then run some projects with mono --llvm --compile-all -v -v -v -v (before and after the change) and get a diff (how many and which methods were modified). The CoreCLR folks use such tools for all jit related PRs