text:
Find Heap Bound

This refactors benchmark/scripts/benchmark_cold_compile.py a little bit and adds an additional script for measuring information about FIRRTL runs: benchmark/scripts/find_heap_bound.py
The basic idea is that you provide a starting heap size (passed via -Xmx), a minimum step size, and JVM arguments and the script will do a binary search to find the minimum allowable heap size. There are sensible defaults for starting heap size and minimum step.
Note that this isn't specific to FIRRTL, you can use this for any java program. The only java specific aspect is that it's using -Xmx.
Use
Help text
$ ./benchmark/scripts/find_heap_bound.py -h
usage: Bound JVM Heap Size [-h] [--verbose] [--start-size START_SIZE]
                           [--min-step MIN_STEP] [--java JAVA]
                           args [args ...]

positional arguments:
  args                  Arguments to JVM, include classpath and main

optional arguments:
  -h, --help            show this help message and exit
  --verbose, -v         Increase verbosity level (cumulative)
  --start-size START_SIZE
                        Starting heap size (default: 4G)
  --min-step MIN_STEP   Minimum heap size step (default: 100M)
  --java JAVA           Java executable to use (default: java)

Example
./benchmark/scripts/find_heap_bound.py --start-size 16G -- -cp utils/bin/firrtl.jar firrtl.stage.FirrtlMain -i regress/Rob.fir -o out -X verilog
Xmx,Max RSS (MiB),Wall Clock (s),User Time (s),System Time (s)
16G,2128,27.64,60.26,5.33
8G,2195,29.08,61.75,4.92
4G,1759,27.67,62.17,4.36
2G,1349,29.29,68.5,4.1
1G,1200,23.02,70.16,2.24
500M,765,27.86,101.59,3.76
400M,674,27.26,111.51,3.91
300M,-,-,-,-
$ echo "
> Xmx,Max RSS (MiB),Wall Clock (s),User Time (s),System Time (s)
> 16G,2128,27.64,60.26,5.33
> 8G,2195,29.08,61.75,4.92
> 4G,1759,27.67,62.17,4.36
> 2G,1349,29.29,68.5,4.1
> 1G,1200,23.02,70.16,2.24
> 500M,765,27.86,101.59,3.76
> 400M,674,27.26,111.51,3.91
> 300M,-,-,-,-
> " | column -t -s,
Xmx   Max RSS (MiB)  Wall Clock (s)  User Time (s)  System Time (s)
16G   2128           27.64           60.26          5.33
8G    2195           29.08           61.75          4.92
4G    1759           27.67           62.17          4.36
2G    1349           29.29           68.5           4.1
1G    1200           23.02           70.16          2.24
500M  765            27.86           101.59         3.76
400M  674            27.26           111.51         3.91
300M  -              -               -              -

This is super useful for examining the tradeoff between heap size, runtime (wall clock) and user time which shows how much extra GC pressure there is.
Future work
It might be nice to search for heap sizes based on different optimization criteria (the current one being "works"). In particular, I think a target user time or perhaps ratio of user time / wall clock time would help find better bounds than just "does it work".
Contributor Checklist

[ ] Did you add Scaladoc to every public function/method?
[ ] Did you update the FIRRTL spec to include every new feature/behavior?
[x] Did you add at least one test demonstrating the PR?
[x] Did you delete any extraneous printlns/debugging code?
[x] Did you specify the type of improvement?
[x] Did you state the API impact?
[x] Did you specify the code generation impact?
[x] Did you request a desired merge strategy?
[x] Did you add text to be included in the Release Notes for this change?

Type of Improvement

new feature/API (for developers)

API Impact
None
Backend Code Generation Impact
None
Desired Merge Strategy

Rebase: You will rebase the PR onto master and it will be merged with a merge commit.

Release Notes
Add script for measuring heap allocation vs. performance and memory use
Reviewer Checklist (only modified by reviewer)

[ ] Did you add the appropriate labels?
[ ] Did you mark the proper milestone (1.2.x, 1.3.0, 1.4.0) ?
[ ] Did you review?
[ ] Did you check whether all relevant Contributor checkboxes have been checked?
[ ] Did you mark as Please Merge?

Also protip, if you paste a CSV into Excel, and then turn the CSV into a normal Excel table, you can copy paste that table into Github and it will autoformat as a table:

Xmx
Max RSS (MiB)
Wall Clock (s)
User Time (s)
System Time (s)

16G
2128
27.64
60.26
5.33

8G
2195
29.08
61.75
4.92

4G
1759
27.67
62.17
4.36

2G
1349
29.29
68.5
4.1

1G
1200
23.02
70.16
2.24

500M
765
27.86
101.59
3.76

400M
674
27.26
111.51
3.91

300M
-
-
-
-

Not sure if this works with GSuite

@seldridge I have incorporated your feedback and rebased on master. I also added another command-line argument --timeout-factor (default 4.0) that allows the script to pick a timeout for java runs since sometimes the JVM can thrash when it's very close to the limit. I had a run of this run all night because of this issue so I figured a timeout is important.

repo: freechipsproject/firrtl


text:
Add custom transforms 'upstream' of emitter annotation in equiv tests

Type of change: bug fix
API impact: none
Backend code-generation impact: none
The LEC environment puts the custom transform annotations later in the annotation sequence than the emitter it selects. Since the transform manager tries to honor this, it ends up running the emitter before the custom transforms if it can.

This results in the tests from #1874 and #1875 failing as expected without the appropriate fixes.

source: gharchive/pull-request

license_type: permissive

license_source: github-api


text:
апдейт

Это собственно виденье списков. Набросал за минуту. Можно, конечно и без Angular, но так как у нас вроде бы "образовательный" проект, то стоит, думаю от тех и других технологий по кусочку брать, чтобы люди смотрели, ковыряли и учились =)

Angular в таком виде — ок. И в дебри пока не погружает, и полноценное приложение.

Посмотреть заготовку можно по адресу https://web-dev-cources-alexbaumgertner.c9users.io/html-prototype/index.html

authors: alexbaumgertner tomkallen

repo: freecodecamp-spb/web-dev-cources

license: mit

license_source: bigquery


text:
hero mdbook, some markdown is not parsed

Situation
Some markdown is not parsed:

- `charts`: helm chart
- `cmds`: includes the project Golang entrypoints
- `docs`: project documentation
- `internal`: contains the explorer API logic and the cert manager implementation, this where most of the feature work will be done
- `pkg`: contains client implementation and shared libs
- `tests`: integration tests
- `tools`: DB tools to prepare the Postgres DB for testing and development
- `rootfs`: ZOS root endpoint that will be mounted in the docker image

It should be like this:

Another example:

It should be this:

can you check this and let me know please @MarioBassem

source: gharchive/issue

authors: Mik-TF despiegk

repo: freeflowuniverse/crystallib


text:
Applying custom styling to SelectList component overrides other styling

@freenow/wave version: 1.18.0

Relevant code
When applying custom styles to the SelectList component using the styles API from react-select, other styles get overwritten.
For example:
<SelectList
  id="select-list-playground"
  isMulti
  hideSelectedOptions={false}
  styles={{
  option: (css, state) => ({
    ...css,
    position: 'relative',
    ...(state.isSelected && {
      '::after': {
        content: '" (selected)"',
      },
    }),
  }),
}}
  label="City"
  onChange={change => console.log(change)}
  options={[
    {
      label: 'Barcelona',
      value: 'bcn',
    },
    {
      label: 'Hamburg',
      value: 'ham',
    },
    {
      label: 'Paris',
      value: 'par',
      isDisabled: true,
    },
  ]}
/>

Produces a select list that looks like this, where the style is overwritten for the pills, disabled state, height of the select list...

Our use case for applying custom styling to the option is that we want to show the "(selected)" text next to the selected ones, to help the user navigate the options. We are currently doing this with JS, but we can simplify the code a lot if custom css was supported here.
What was expected to happen?
Styles should be merged?
Reproduction

https://codesandbox.io/s/wave-playground-forked-oq8jpd?file=/src/App.js

I like this request as it also affects our case were we want the mandatory option in a multi select not to be clearable.

The "Fixed" option is already part of the original React Select  component that we use as a basis. So it should be possible to use this. We also have a tag component with dismissible={false} option https://wave.free-now.com/components/tag

authors: bluessista jonotrujillo rafael-sepeda

repo: freenowtech/wave


text:
Fixed wrong token displayed on search

The correct token should now be displayed on search and also drag & drop regardless of the whether the token is locked or not.

Signed off by Mulili Nzuki mulili.nzuki@gmail.com

@justin-stephenson this should fix the wrong token display issue when searching locked and non-locked tokens. Please test and lmk how it goes, thanks :)

Thank you @mul1sh This looks good in my initial testing, i'll merge this after doing more verification on my end.

@mul1sh I propose to disable the long press token re-ordering when using the search bar, I noticed some issues here and I don't see the need to re-order tokens while searching/filtering tokens. Would you mind updating the PR for this?

@mul1sh I propose to disable the long press token re-ordering when using the search bar, I noticed some issues here and I don't see the need to re-order tokens while searching/filtering tokens. Would you mind updating the PR for this?

No worries, I've pushed another commits which has disabled re-ordering of tokens when searching 🙂

Thank you @mul1sh !

repo: freeotp/freeotp-ios


text:
Parameterized implicits handlers

Following this example https://github.com/frees-io/freestyle-cassandra-example/blob/master/basic/src/main/scala/freestyle/cassandra/sample/Implicits.scala#L42, I just seen that these implicits should be in the library.
I am starting to use in a real project and I would have to copy and paste these implicits but in my case, using Try vs Monix.
Apart form that, in others librarys we are providing these implicits.
What do you think @fedefernandez @FPerezP ?

These implicits depend on the Session and Cluster instances and on the MonadError of monix. I agree with you, we could provide these implicits based on an existing MonadError instance:
implicit def clusterAPIInterpreter[M[_]](implicit cluster: Cluster, E: MonadError[M, Throwable]): ClusterAPI.Op ~> M = clusterAPIHandler[M] andThen apiInterpreter[M, Cluster](cluster)

authors: eperinan fedefernandez

repo: frees-io/freestyle-cassandra


text:
Animate open/close for select

We should animate the Select dropdown, like we do with i.e. Accordion

@Steinop  har du noen tanker på denne?

Based on accordion sounds fine. Let's try it out.

authors: Mikkelinski Steinop piofinn

repo: fremtind/jokul

license: MIT


text:
Forsøk på bloggpost

Kopiert inn dokumentasjon fra Figma om hvordan vi bruker Figma i Fremtind. Litt usikker på om jeg fikk til bildet eller om det må få en satt størrelse eller noe også for å se bra ut.
Ta gjerne en titt på om innholdet gir mening også

Bare ren tekstpirk fra meg. Super bloggpost @Mikkelinski 😁
Bør det også stå noe om hvem som er master administrator (den nye Mikkel, eller hva det nå heter...). Greit å vite hvem man skal henvende seg til

Supert - har rettet opp. Ang master admin venter jeg på det til jeg vet sikkert hvem det blir heh

Veldig kult @Mikkelinski , hvordan opplevde du å skrive blogpost som dette fra et designer perspektiv?

Veldig kult @Mikkelinski , hvordan opplevde du å skrive blogpost som dette fra et designer perspektiv?

Ganske lett - er jo samme som øvrige sider -  litt spent på om bildet funker som jeg vil derimot heh

@piofinn står at jeg ikke har authorization til å merge denne btw

authors: Mikkelinski lfbergee


text:
[Recursive solutionfor Coin Change]

Algorithm

[ ] I have gone through the repository and made sure this algorithm has not been implemented

Information about my new algorithm

Recursive Coin Change

C++:

Time complexity:

Is this your first contribution to this repository?
Yes

@frextrite  review my pr #351


text:
Finishing up

Description
This issue describes the set of tasks to complete in order to finish up work on the library.
Tasks

[ ] Touch base with the @jobarratt and @pwalsh to notify that you consider the work complete
[ ] Provide a short description / link to code for how each action is implemented, with a link to unit tests that prove each action
[ ] Tag your candidate code as v0.1
[ ] Setup travis to auto deploy tagged versions to the package management solution for your language
[ ] Ensure that the OKI account on the package management platform is an administrator/maintainer of the package, along with yourself
[ ] Receive code review from @pwalsh and address any remaining issues
[ ] Publish final version

@georgeslabreche
Are we ok to close this one?

authors: pwalsh roll

repo: frictionlessdata/datapackage-java


text:
Eliminate use of Object.assign. Fixes #142

When the bundle was created by babel, calls to Object.assign were being
left as-is, causing errors in IE 11 that left the user staring at a
blank screen.
Fixes #142

Coverage decreased (-0.03%) to 96.07% when pulling c91cc3ac31741f42d4042fbb8f5103f10c81f11e on fritz-c:master into 4630d1961dbf65772fc957bb36a38cbfcb072318 on fridays:master.

Thanks for contributing! I think it should be taken care of by next/babel. Do you use a custom babel file, and can you check if it's happening too with only a bare Next.js project?

I wasn't using a custom babel file.
Here is an minimal reproduction repo: https://github.com/fritz-c/next-routes-ie

I suppose the issue with next/babel could be traced back to one of these changes: https://github.com/zeit/next.js/commits/ebf0c47c25541cfc50c8f319141f4bc9f47daeb8/server/build/babel/preset.js

I am seeing the same issue in IE11, and my custom babel file is below: (I need it for the test framework)
{
    "env": {
      "development": {
        "presets": ["next/babel"]
      },
      "production": {
        "presets": ["next/babel"]
      },
      "test": {
        "presets": [["next/babel", { "preset-env": { "modules": "commonjs" } }]]
      }
    }
  }

Including a polyfill in my Layout component works for now but isn't optimal.

As stated in the Next.js docs, you should handle polyfills yourself. There is an example showing how to do it. See:
https://github.com/zeit/next.js#browser-support
Perhaps a warning in the docs would suffice?

If we can easily switch out Object.assign and avoid babel configuration issues with no additional ongoing maintenance I'd argue that it makes sense? I'd forgotten I added the polyfill but this is something I'll be coming back to resolve soon, whether it be with babel or a fork of this repo.

Has anyone released a fork without the usage of Object.assign? This method isn't supported by IE 11 (~2% of traffic) and Chrome 41 (googlebot!).

authors: coveralls fridays fritz-c jonjamz oliviertassinari stevokk

repo: fridays/next-routes


text:
Conflicts: Scheduling vs Synchronization

Hi,
sabre/dav makes some changes on the server-side calendar objects when updating PARTSTAT of participants (iTip local delivery processing), that could conflict with local-side changes.
Scenario:

Organizer creates a calender object and invites Bob and Alice, both local accounts.
sabre/dav creates three calendar objects: one in Organizer calendar, one in Alice calendar, one in Bob calendar. Let's say for simplicity that all calendars have a sync token of 1 and all calendar objects an etag E1 at this point.
Now, Bob and Alice both synchronize their agendas and get the invite.
Bob ACCEPT the invite and tries to synchronize its calendar.
Bob synchronization works as expected. sabre/dav updates the calendar objects of Organizer, Bob and Alice with Bob PARTSTAT:ACCEPTED. When doing that, sabre/dav increments all agendas (Organizer, Bob and Alice) sync token to 2 and all calendar objects to etag E2.
Alice has not synchronized yet. Locally, she's still at sync token 1.
Alice ACCEPT the invite and tries to synchronize its agenda.
CONFLICT. Alice is using iOS or DAVDroid. Before doing the request, these CalDAV clients do a PROPFIND. Alice CalDAV client recognizes that the calendar object has changed on the server, due to sync token = 2 and etag E2. Her local change (Alice PARTSTAT:ACCEPTED) is never sent to the server. Instead, the CalDAV client overwrites Alice local calendar object with the server version (where Bob is PARTSTAT:ACCEPTED).

Nobody knows that Alice accepted the event. Poor Alice.
My purpose is to use CalDAV to manage events with numerous participants (members of the site), that could answer via Web or via phone. I can't expect everybody to always be in sync with the server when replying to the event.
I believe this is more a specification (RFC) problem than a bug, but I'd like to have your opinion and eventual workaround.
I don't see how sabre/dav could handle this: not updating the event during synchronization is a bad option, and there's no way for sabre to know if the synchronization will follow a PUT request or not. Maybe the client should better handle conflicts, but who's going to tell Apple to better manage conflicts if that's not specified in the RFC...

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/33720252-conflicts-scheduling-vs-synchronization?utm_campaign=plugin&utm_content=tracker%2F294006&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F294006&utm_medium=issues&utm_source=github).

Hi @kriswebdev ,
There is something called a 'Schedule-Tag' which is something sabre/dav does not yet implement. It's a bit of a looser version of the ETag. I don't know 100% sure but if it's supported it may solve your problem. I believe so at least =) What I don't know is if apple products implement it.
So for now the sanest thing seems to be to close this ticket as a duplicate of #501

authors: evert kriswebdev

repo: fruux/sabre-dav


text:
Non-executable build.sh generated

When running forge new project --name Api --folder ./Api --template suave, a file called build.sh is created, but its flags don't include the executable bit. It should, because it should be possible to build directly after creating the project without knowing how to use chmod on Unix systems.

I don't know a lot about *nix OSes but shouldn't https://github.com/fsharp-editing/Forge/blob/master/src/Forge.Core/Templates.fs#L196-L197 be enough?

Even if it is File.WriteAllText recreates the file here.

:facepalm:

🤦

authors: Krzysztof-Cieslak haf

repo: fsharp-editing/Forge

license: unlicense


text:
Build FAILED '2.6.4' of package 'NUnit' -- Mono Ubuntu

:/usr/local/src/fsharp$ ./autogen.sh --prefix=/usr/local
checking whether make sets $(MAKE)... yes
checking for pkg-config... /usr/bin/pkg-config
configure: "pkg-config: /usr/bin/pkg-config"
configure: "PKG_CONFIG_LIBDIR: "
checking for xbuild... /usr/local/bin/xbuild
configure: xbuild: /usr/local/bin/xbuild
configure: PCL Reference Assemblies for Profile 47 found: no
configure: PCL Reference Assemblies for Profile 47 found: no
configure: PCL Reference Assemblies for Profile 7 found: no
configure: PCL Reference Assemblies for Profile 78 found: no
configure: PCL Reference Assemblies for Profile 259 found: no
configure: creating ./config.status
config.status: creating launcher
config.status: creating Makefile
config.status: creating config.make
config.status: creating src/fsharp/Makefile
config.status: creating src/fsharp/FSharp.Build-proto/Makefile
config.status: creating src/fsharp/FSharp.Compiler-proto/Makefile
config.status: creating src/fsharp/Fsc-proto/Makefile
config.status: creating src/fsharp/FSharp.Core/Makefile
config.status: creating src/fsharp/FSharp.Build/Makefile
config.status: creating src/fsharp/FSharp.Compiler/Makefile
config.status: creating src/fsharp/Fsc/Makefile
config.status: creating src/fsharp/FSharp.Compiler.Interactive.Settings/Makefile
config.status: creating src/fsharp/FSharp.Compiler.Server.Shared/Makefile
config.status: creating src/fsharp/FSharp.Data.TypeProviders/Makefile
config.status: creating src/fsharp/fsi/Makefile
config.status: creating src/fsharp/fsiAnyCpu/Makefile
config.status: creating src/fsharp/policy.2.0.FSharp.Core/Makefile
config.status: creating src/fsharp/policy.2.3.FSharp.Core/Makefile
config.status: creating src/fsharp/policy.3.3.FSharp.Core/Makefile
config.status: creating src/fsharp/policy.3.7.FSharp.Core/Makefile
config.status: creating src/fsharp/policy.3.47.FSharp.Core/Makefile
config.status: creating src/fsharp/policy.3.78.FSharp.Core/Makefile
config.status: creating src/fsharp/policy.3.259.FSharp.Core/Makefile
config.status: creating src/fsharp/policy.4.0.FSharp.Core/Makefile
config.status: creating src/fsharp/policy.4.3.FSharp.Core/Makefile
:/usr/local/src/fsharp$ make
make -C src/fsharp all
make[1]: Entering directory '/usr/local/src/fsharp/src/fsharp'
make build-proto
make[2]: Entering directory '/usr/local/src/fsharp/src/fsharp'
cp -p /usr/local/src/fsharp/lib/bootstrap/4.0/FSharp.Core.dll /usr/local/src/fsharp//lib/proto/FSharp.Core.dll
cp -p /usr/local/src/fsharp/lib/bootstrap/4.0/FSharp.Core.sigdata /usr/local/src/fsharp//lib/proto/FSharp.Core.sigdata
cp -p /usr/local/src/fsharp/lib/bootstrap/4.0/FSharp.Core.optdata /usr/local/src/fsharp//lib/proto/FSharp.Core.optdata
make -C FSharp.Build-proto Configuration=proto build-proto
make[3]: Entering directory '/usr/local/src/fsharp/src/fsharp/FSharp.Build-proto'
MONO_ENV_OPTIONS= /usr/local/bin/xbuild /p:Configuration=Proto
XBuild Engine Version 12.0
Mono, Version 4.3.0.0
Copyright (C) 2005-2013 Various Mono authors
Build started 8/10/2015 8:37:49 AM.

Project "/usr/local/src/fsharp/src/fsharp/FSharp.Build-proto/FSharp.Build-proto.fsproj" (default target(s)):
Target CallFsSrGen:
Skipping target "CallFsSrGen" because its outputs are up-to-date.
Target BeforeBuild:
Executing: mono --runtime=v4.0.30319 /usr/local/src/fsharp/src/fsharp/FSharp.Build-proto/../../../.nuget/NuGet.exe restore packages.config -PackagesDirectory packages
WARNING: Error: SendFailure (Error writing headers)
WARNING: Error: SendFailure (Error writing headers)
Unable to find version '2.6.4' of package 'NUnit'.
Unable to find version '2.6.4' of package 'NUnit.Runners'.
/usr/local/src/fsharp/src/FSharpSource.targets: error : Command 'mono --runtime=v4.0.30319 /usr/local/src/fsharp/src/fsharp/FSharp.Build-proto/../../../.nuget/NuGet.exe restore packages.config -PackagesDirectory packages' exited with code: 1.
Task "Exec" execution -- FAILED
Done building target "BeforeBuild" in project "/usr/local/src/fsharp/src/fsharp/FSharp.Build-proto/FSharp.Build-proto.fsproj".-- FAILED
Done building project "/usr/local/src/fsharp/src/fsharp/FSharp.Build-proto/FSharp.Build-proto.fsproj".-- FAILED
Build FAILED.
Errors:
/usr/local/src/fsharp/src/fsharp/FSharp.Build-proto/FSharp.Build-proto.fsproj (default targets) ->
/usr/local/src/fsharp/src/FSharpSource.targets (BeforeBuild target) ->
/usr/local/src/fsharp/src/FSharpSource.targets: error : Command 'mono --runtime=v4.0.30319 /usr/local/src/fsharp/src/fsharp/FSharp.Build-proto/../../../.nuget/NuGet.exe restore packages.config -PackagesDirectory packages' exited with code: 1.

 0 Warning(s)
 1 Error(s)

Time Elapsed 00:00:01.7554000
Makefile:9: recipe for target 'build-proto' failed
make[3]: *** [build-proto] Error 1
make[3]: Leaving directory '/usr/local/src/fsharp/src/fsharp/FSharp.Build-proto'
Makefile:15: recipe for target 'build-proto' failed
make[2]: *** [build-proto] Error 2
make[2]: Leaving directory '/usr/local/src/fsharp/src/fsharp'
Makefile:10: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/usr/local/src/fsharp/src/fsharp'
Makefile:4: recipe for target 'all' failed
make: *** [all] Error 2

Hi @igouy. Which version of mono are you using? (mono --version)

Mono JIT compiler version 4.3.0 (master/906ff55 Sun Aug  9 22:49:27 PDT 2015)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS:           __thread
SIGSEGV:       altstack
Notifications: epoll
Architecture:  amd64
Disabled:      none
Misc:          softdebug
LLVM:          yes(3.6.0svn-mono-master/a92ada2)
GC:            sgen

Hmm, I think this is most likely a temporary NuGet issue, as it works here with 4.0.2 and 4.3.0 (from Thursday). If this is the first mono installation on this machine you may need to run mozroots --import --sync.

I've been trying to build F# 4 for about a week, since I saw the release announcement.
I started off trying to build F# 4 with -- Mono JIT compiler version 4.3.0 (master/54e8010 Sun May 31 13:36:15 PDT 2015) -- and hit this same problem.
Yesterday I burned a couple of hours building LLVM for Mono, and then building Mono, and now...

Perhaps a certificate problem?  Can you get any nuget packages on that machine?

The error is definitely here:
Executing: mono --runtime=v4.0.30319 /usr/local/src/fsharp/src/fsharp/FSharp.Build-proto/../../../.nuget/NuGet.exe restore packages.config -PackagesDirectory packages  WARNING: Error: SendFailure (Error writing headers)  WARNING: Error: SendFailure (Error writing headers)

See here (after searching Google for "SendFailure (Error writing headers)")
http://stackoverflow.com/questions/25081384/mono-httpwebrequest-over-ssl-error-writing-headers

That is, try
mozroots --import --sync

Another comment in the SO reply:

if you run your program with "sudo mono", adding the certs to the user store will not be enough. You would have to add them to the machine store by passing "--machine". This took me a while to figure it out

mozroots --import --sync
Seems to be building.
Another comment in the SO reply says "Mono 3.12, or above, has removed the need to run mozroots".

I did not experience this problem building F# 3.1 on the same machine against the same Mono install back on May 31.

Yes, I agree, I remember the comment that mozroots is no longer needed. @migueldeicaza or @directhex might know if something is up - or maybe the other certificate roots on your machine are somehow out of sync.

In any case, closing this here - if you can isolate the problem with Mono then please add a bug to http://bugzilla.xamarin.com

@dsyme 3.12 and above include the "cert-sync" tool, which converts a user's OS-wide certificate store to Mono's cert store format. All our RPMs and .debs run cert-sync at install time. If users go out of their way to avoid using the helpers they're provided with, that's sorta out of my hands

Ah ok, thanks @directhex.  So I suppose this isn't run on a fresh build of Mono from source.

Mono from source?
Is the cert-sync run as part of mono's install target, or is it only a debian-package routine?

There's no sane way to run it via "make install", because there's no standard location for the cert store on Linux - if there was, frankly, we could just consume it directly.

http://www.mono-project.com/docs/about-mono/releases/3.12.0/#cert-sync

Thanks

authors: directhex dsyme igouy knocte rneatherway

repo: fsharp/fsharp


text:
Concurrency and CPU usage

Testing using AMD with 64 cores.
If run at concurrency 50, works for a budget or two then gives 'game incomplete' fail.
Same situation concurrency at 40, 30.
Concurrency 20 works (so far).
Observing the CPU usage, there's a demand spike at the end of each game run (one budget), which for concurrency 30, 40, 50 takes CPU usage to 100% and the system gets its knickers in a twist and starts reporting fails.
At concurrency 20. CPU usage is 44%, 255 processes, 3372 threads, and 79Gb RAM in use.
At the end of each game run (one budget), CPU usage doubles to 80%, processes to 333, threads to 3590 and RAM to 131 GB. I'm getting away with concurrency 20, so far.
Guessing here, but it looks like, at the end of each budget for some reason, it fires up both master and test engines (2x20) and does some processing, using 40(?) cores for a few seconds?
It fails for high concurrency, because 60, 80, 100 core fire ups are too much for it? Well, too much when using my engine.
Is there anyway to lower the increased core demand at the end of each budget?

Does this happen when using stockfish?

SF runs okay (so far) with 60 concurrency, but it puts much less load on the CPU. 18% at concurrency 60. But still shows the spike demand at the end of each game cycle (each budget) to about 44%
I also tried 500 game cycles, and depth 9, to see if it loaded more, yes, but not by much.
.
Quite probably SF is way more efficiently organised, memory-wise, than mine. Even so, the doubling of CPU demand at cycle end is weird. Be good if checked it out, and batched or time delayed (?) so not everything core-wise was being hit at once?

Because the memory and CPU demand spikes (doubling) happen at the end of each budget, I wonder if you're closing all engines out, and then opening them up again, such that there's overlap? New invocations opening before the old invocations are finished off with ending? That might account for the doubling.

Because the memory and CPU demand spikes (doubling) happen at the end of each budget, I wonder if you're closing all engines out, and then opening them up again, such that there's overlap? New invocations opening before the old invocations are finished off with ending? That might account for the doubling.

Only after each budget engines are restarted.

SF runs okay (so far) with 60 concurrency, but it puts much less load on the CPU. 18% at concurrency 60. But still shows the spike demand at the end of each game cycle (each budget) to about 44%

What time control or depth did you use for this test?

Quite probably SF is way more efficiently organised, memory-wise, than mine. Even so, the doubling of CPU demand at cycle end is weird. Be good if checked it out, and batched or time delayed (?) so not everything core-wise was being hit at once?

After a budget all engines are quitted. Then its time for nevergrad to update the params. I will try to add a log to measure the cpu and ram usage and time elapsed when nevergrad is updating its thing.

Giving back memory from many processes may be taking time?
It’s for sure there are 2xN engine threads running/opening/closing simultaneously because of the RAM usage doubling during the CPU usage spike. It can’t be nevergrad grabbing RAM, the amount is too large and more or less exactly matches what N engines grab.
Maybe it’s possible to await engine close signals  before starting up again?

Created a branch https://github.com/fsmosca/Lakas/tree/more_logging
You need psutil for this.
pip install psutil
It will log to match_lakas.txt for the usage of cpu when nevergrad updates its data.
sample:
Initial:
2021-02-13 09:53:42,317 |  12048 | INFO  | starting main()
2021-02-13 09:53:42,581 |  12048 | INFO  | budget 1, after asking recommendation      , proc_id: 12048, cpu_usage%: 0, num_threads: 8, proc_name: python
2021-02-13 09:53:42,584 |  12048 | INFO  | before a match starts                      , proc_id: 12048, cpu_usage%: 0, num_threads: 8, proc_name: python

budget 2, after asking recommendation      , proc_id: 12048, cpu_usage%: 12, num_threads: 8, proc_name: python

budget 3, after asking recommendation      , proc_id: 12048, cpu_usage%: 10, num_threads: 8, proc_name: python

Using stockfish with concurrency 6 on my 4-core/8-thread PC, optimizer uses around 12% of python alone. In my other tests it reached 25%, this is the highest I observed.
Note match_lakas.txt can get very big as it logs the engine output from cutechess-cli.
If you test it, just use a smaller budget of 4 or so or interrupt after couple of budgets.
Later I will log the memory used.

Giving back memory from many processes may be taking time?

That is possible, I am working on logging memory usage later.

It’s for sure there are 2xN engine threads running/opening/closing simultaneously because of the RAM usage doubling during the CPU usage spike. It can’t be nevergrad grabbing RAM, the amount is too large and more or less exactly matches what N engines grab.
Maybe it’s possible to await engine close signals before starting up again?

cutechess-cli has -wait N
Wait N milliseconds between games. The default is 0
I will add it as an option later.
Or  you can modify the code at https://github.com/fsmosca/Lakas/blob/1c5201e7f9ce5534e18a5791f377101bc9a7f374/lakas.py#L299
Just add
command += ' -wait 5000'
to wait for 5 seconds.

The more logging branch at https://github.com/fsmosca/Lakas/tree/more_logging is updated:
v0.23.3
commit summary

Add --cutechess-debug flag
Add memory used by python when optimizer updates its data
Add --cutechess-wait option

--move-time-ms 10 seems to work (budget about twice as fast as with move-time-ms 25).
the default wait (code looks like it defaults to 5000 ms, if I read it correct) doesn't help with the CPU load, which is still doubling at the end of each budget.
it may be that I am just being too careless with RAM usage (256 Gb available, makes you lazy). When a process is ended, it has to clear the RAM it gives back (windows security reasons), so overlap exit-start, is going to have cores=concurrency x 2 with that many cores busy nulling out RAM given back. No doubt the RAM is segmented all over the place by concurrent starts.
What is cutechess doing? a 5000 ms wait AFTER it closes an engine? Because that ought to work. Weird.

Yes default wait is 5000 ms in lakas.
From cutechess:
-wait N		Wait N milliseconds between games. The default is 0.
Looks like:

game starts
game ends
wait N

Master is now updated with some changes including that of more logging branch.

Maybe related to a known issue of cutechess: https://github.com/cutechess/cutechess/issues/630

authors: ChrisWhittington Matthies fsmosca

repo: fsmosca/Lakas


text:
External References

At the moment if you reference an external f# file in your project the JavaScript output for the reference file is the original folder… Which is bad new if you have a few projects referencing it with different fable options.  Even worse, if you are using the outDir option the resulting path is relative to the outDir so you end up with unexpected locations for the js files.
This tries to solve the problem by placing these external files in a “.fabel.external” folder with a hash code (of the path) to avoid name collisions.

Need a bit more testing...

This is a very good idea! I would just add a compiler flag for activation as this may not be the desired behaviour for all users. I will bring it to a separate branch for now to add this and some testing. Thanks a lot for your work!

@davidtme, do you have any preference for the name of the compiler flag to activate this feature?

@alfonsogarciacaro I haven't really got a preference, maybe something along the lines of shadow external?

Ideally should be something short. It's difficult to convey the whole meaning with just the flag but then we have the help text for that. I was thinking of --copyExt, what do you think?

Superseded by #111

authors: alfonsogarciacaro davidtme

repo: fsprojects/Fable


text:
paket pack fails when there is no build configuration named "Release"

csproj (irrelevant lines removed):
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x86'">
    <OutputPath>..\..\build\bin\dialer\</OutputPath>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="System" />
  </ItemGroup>
  <ItemGroup>
    <Compile Include="Program.cs" />
  </ItemGroup>
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
</Project>

As you can see we only have the "Release|x86" config. Paket 1.32 packed this just fine with type project in paket.template, but 2.28 yields:
.paket/paket.exe pack output build/deploy
Paket version 2.28.0.0
Paket failed with:
	Unable to find Release output path node in file above.csproj

I don't know how the "find output path" logic changed in particular, but maybe use "Release.*" as a fallback when looking for the OutputPath.

I created a failing test in 106215a
@amazingant do you have an idea how we can handle this?

@forki I know this isn't the desired answer, but this behavior looks correct to me. The shortened project file from @agross says on line 6 to target AnyCPU if a platform isn't specified, and there isn't a Release build configuration for AnyCPU. IMO, fixing this accurately would mean adding a platform parameter to paket's pack command, or perhaps just some kind of projectflag parameter that could be given multiple times? e.g., paket pack output build/deploy projectflag Platform=x86.
To quickly patch over this and get the issue resolved, ProjectFile.GetOutputDirectory could just call GetPropertyWithDefaults multiple times with different platform options and use the first one with a result.

@amazingant One could argue the project file is incorrect. What should be fixed, in your opinion?
I'm not saying paket shouldn't change its "finding" logic, rather that VS created the csproj and it seems legit to VS, but not paket.

(just to clarify why the older version worked. At that time we didn't analyzed at all, so by pure luck it worked)

@agross Knowing that you can do this in VS' configuration manager, your project file looks perfectly legitimate to me:

(I think VS keeps this information in the solution file?) Unfortunately, paket doesn't know about this "Debug means x86 for project Y and AnyCPU for project Z" info.
Perhaps the best way to handle this would be to add an optional parameter to the pack command, and if it isn't provided, try all of the known platform targets and see if any result in an output path. It would allow being explicit about what you want, but it would also resolve your issue without you having to change anything.
Your thoughts, @forki? There's a nice list of platforms from the C# compiler documentation here that paket could check against.

mhm. at the moment we don't report any path, right? Maybe we should default to whatever we find with release then!?

@amazingant

I think VS keeps this information in the solution file?

Yes, this is the case here.

and if it isn't provided, try all of the known platform targets and see if any result in an output path

That would be fine with me. In this case, perhaps log some warnings about that and tell the user what platforms have been tried and which has been selected.

@amazingant
Thank you very much, our build turned green again :-)
I think the output can be improved when you have multiple paket.template files. What do you think?
No platform specified; found output path node for the x86 platform after failing to find one for the following: AnyCPU32BitPreferred, AnyCPU
No platform specified; found output path node for the AnyCPU platform after failing to find one for the following:
No platform specified; found output path node for the AnyCPU platform after failing to find one for the following:
No platform specified; found output path node for the x86 platform after failing to find one for the following: AnyCPU32BitPreferred, AnyCPU
No platform specified; found output path node for the AnyCPU platform after failing to find one for the following:
No platform specified; found output path node for the AnyCPU platform after failing to find one for the following:
Packed: Foo\paket.template
Packed: Bar\paket.template
Packed: Baz\paket.template

@agross Just took a look at the build output for one of my projects and saw the same. Initially confused me seeing after failing to find one for the following: with nothing "following". I'll take a look at this when I get a chance, and see if I can clean it up.

:+1: That would be great!

authors: agross amazingant forki

repo: fsprojects/Paket


text:
Support for groups in paket.local

Description
paket.local does not support groups - only main group is currentyl supported
See Note: in http://fsprojects.github.io/Paket/local-file.html#Format
I'm willing to take care of this soon

+1
Waiting for it... really!

authors: theimowski xlegalles


text:
Use reflection to get source location when FCS doesn't give enough information

Partial fix for #947 (NOT YET READY).
For Octokit NuGet package, FCS returns faulty ranges (no range or a dummy range with wrong information). We try to use Reflection to recover source locations. I'm not sure it's a good approach; any other idea is appreciated.
@ctaggart It seems pdbReader.GetMethod doesn't work correctly for any overriden/abstract member e.g. any symbol from this line:
let a = github.Activity.Events.GetAll()

Is this a SourceLink's bug? Any idea?

@ctaggart I need your help with this one to move forward. Should I wait for changes in SourceLink or discard this PR as we don't support source-indexed C# assemblies at this point?

As I just mentioned in ctaggart/SourceLink#63, not all files or methods gets indexed by the compilers. F12 at design time will only work with concrete methods that get source indexed, not any of the interfaces.

That sounds really limiting. On a related note, can signature files (*.fsi) be source indexed?

Closing this PR until there is more versatile support for pdb files from SourceLink.

I believe Portable PDBs https://github.com/ctaggart/SourceLink/issues/93 will solve several of the issues here. I'll create a new issue here.

authors: ctaggart dungpa

repo: fsprojects/VisualFSharpPowerTools


text:
Question about _put_file/upload

Hi Community,
I have questions about _put_file.
In the multipart upload of _put_file function, I noticed that we are sending a request at a time instead of sending all request at a single time and join them. The latter seems to be faster in my opinion. (I think the idea can also be applied to _get_file/download)
Is there any reason why we do this?
Would be happy to discuss and contribute, thank you!

It would be reasonable to write multiple pieces asynchronously. However, the pieces are necessarily large (otherwise a single call is enough), so I very much doubt there would be any time to be saved. The async route will require much more memory, since it would load many blocks of data at once.
Would you mind doing a speed-test to prove that async operation is clearly better?

Yes I agree with your point.
Only when the pieces are large enough, we will get performance improve. Also, async route will require more memory at a single time.
I can try to implement it and test the performance and we can have further discussion :)
Btw, what would be the typical way to test the upload/download speed? Should I directly use a S3 to test or there are other better ways?

authors: martindurant troychiu


text:
chore(main): release veto 0.1.1

:robot: I have created a release beep boop
0.1.1 (2024-04-12)
Bug Fixes

veto: add keywords (1f5672c)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/fuf-stack/uniform/releases/tag/veto-v0.1.1 :sunflower:

repo: fuf-stack/uniform


text:
[FEATURE] Add fugue to conda-forge

Is your feature request related to a problem? Please describe.
fugue isn't available on conda yet, packages with non-python dependencies are usually more easily installed via conda
Describe the solution you'd like
conda install fugue -c conda-forge

The following dependencies need to be added to anaconda (conda-forge requires all dependencies be on the conda-forge channel) to make this possible:

[x] adagio: github, dependencies: only triad not on anaconda
[ ] qpd: pypi, dependencies: only triad not on anaconda (the hompage link to the github is broken so found by extracting setup.py from the tar.gz file)
[x] triad - all dependencies on anaconda

I added a package (ploomber) to conda-forge, and am happy to do the same for fugue

Additional tasks:

[ ] (optional) Update fugue Makefile make setupinconda for conda-forge install
[ ] (Optional) Add an environment.yml for local development
[ ] Update README with conda badges
[ ] Open source qpd (conda-forge requires a LICENSE)

That will be fantastic!!
@rdmolony can you join the slack channel let's chat about the details? I started a little bit on the conda side long time ago, it would be great if you can drive this.

No problem @goodwanghan :)

Happy to Kevin, please feel free to add any tasks you can think of to the list above

Actually, I realized makeinconda is for the installation of a development environment. We probably just want to update the README as you have above.

Ref conda-forge/staged-recipes#16044
Ref conda-forge/staged-recipes#16099

This got done. We are on conda-forge: https://anaconda.org/conda-forge/fugue

authors: goodwanghan kvnkho rdmolony

repo: fugue-project/fugue


text:
Mobile friendly color picker

With the current layout, on responsive website, the color picker might exceed page browser width when viewed on mobile browser. Meanwhile, on websites without responsive design, users have to zoom and pan to move the sliders.
An alternative mobile friendly layout would be good. Perhaps a popup dialog style on the center of the screen, or a keyboard popup style on appearing on the bottom of the screen. Either way, it should also come with an option to automatically switch layout between popup or dropdown depending on the screen size, instead of forcing to use one layout.

Feature added at commit f24e21b5a8169df060232be89101d87cfee23c0a

repo: fujaru/jquery-wheelcolorpicker


text:
MobA: 効率的なモバイルタスク自動化のための二層エージェントシステム

タイトル: MobA: 効率的なモバイルタスク自動化のための二層エージェントシステム
リンク: https://arxiv.org/abs/2410.13757
概要:
現在のモバイルアシスタントは、システムAPIに依存しているため制限が多い、あるいは、複雑なユーザー指示や多様なインターフェースへの対応に苦労しています。これは、理解力と意思決定能力が限られているためです。これらの課題に対処するため、私たちはMobAを提案します。MobAは、マルチモーダル大規模言語モデルを搭載した新しいモバイルフォンエージェントであり、洗練された2レベルのエージェントアーキテクチャを通じて、理解力と計画能力を向上させています。高レベルのグローバルエージェント（GA）は、ユーザーコマンドの理解、履歴メモリの追跡、タスクの計画を担当します。低レベルのローカルエージェント（LA）は、GAからのサブタスクとメモリをガイドに、関数呼び出しの形式で詳細なアクションを予測します。リフレクションモジュールを統合することで、効率的なタスク完了が可能になり、システムはこれまで見たことのない複雑なタスクにも対応できます。MobAは、実際の評価において、タスク実行の効率と完了率の大幅な向上を示しており、MLLMを搭載したモバイルアシスタントの可能性を明確に示しています。

論文要約
論文要約: MobA: 効率的なモバイルタスク自動化のための二層エージェントシステム

従来のモバイルアシスタントの問題点:

システムAPIへの依存による機能制限
複雑な指示や多様なインターフェースへの対応不足
理解力と意思決定能力の限界

MobAの提案:

マルチモーダル大規模言語モデルを搭載した新しいモバイルフォンエージェント
洗練された二層エージェントアーキテクチャによる理解力と計画能力の向上

二層エージェントアーキテクチャ:

高レベルのグローバルエージェント (GA): ユーザーコマンドの理解、履歴メモリの追跡、タスクの計画を担当
低レベルのローカルエージェント (LA): GAからのサブタスクとメモリをガイドに、具体的なアクションを関数呼び出しの形式で予測

リフレクションモジュール:

効率的なタスク完了を可能にする
未知の複雑なタスクへの対応力向上

評価結果:

タスク実行の効率と完了率の大幅な向上
MLLM搭載モバイルアシスタントの可能性を実証

@yukihiko-fuyuki が以下のラベルを提案し、適用しました：

llm
mobile
task-automation

以下の新しいラベルが作成され、適用されました：

mobile
task-automation

repo: fulfulggg/Information-gathering


text:
added handling for cancelation

Currently with Twitter authentication, android app is crashed when it's canceled. This PR is to avoid this.  This patch will fix the issue but it's for twitter and would not be general oauth1.

For #65

repo: fullstackreact/react-native-oauth


text:
There is no mac address of our device

How can we find the mac address of our device which is also attached to this network?

This library shows just the arp table. There is no personal mac address in arp table.
Closing the issue for OT


text:
cryptic css import error

To Reproduce

in turborepo cd apps
init a fumadocs app with pnpm create fumadocs-app
run pnpm add fumadocs-twoslash

tsconfig.json:
{
  "extends": "@repo/tsconfig/nextjs.json",
  "compilerOptions": {
    "tsBuildInfoFile": "node_modules/.cache/tsbuildinfo.json",
    "baseUrl": ".",
    "incremental": true,
    "paths": {
      "@/*": ["./*"]
    },
    "plugins": [{ "name": "next" }]
  },
  "include": [
    "next-env.d.ts",
    "**/*.ts",
    "**/*.tsx",
    ".next/types/**/*.ts",
    "next.config.mjs",
    "tailwind.config.ts"
  ],
  "exclude": ["node_modules", ".next"]
}

next.config.mjs:
import { createMDX } from "fumadocs-mdx/next";

const withMDX = createMDX();

/** @type {import('next').NextConfig} */
const config = {
  reactStrictMode: true,
  transpilePackages: ["@repo/ui"],
};

export default withMDX(config);

tailwind.config.ts:
import baseConfig from "@repo/ui/tailwind.config";
import { createPreset } from "fumadocs-ui/tailwind-plugin";
import type { Config } from "tailwindcss";

const webConfig = {
  ...baseConfig,
  presets: [
    createPreset({
      preset: "black",
    }),
  ],
  content: [
    ...baseConfig.content,
    "../../packages/ui/src/**/*.{ts,tsx}",
    "./components/**/*.{ts,tsx}",
    "./app/**/*.{ts,tsx}",
    "./content/**/*.{md,mdx}",
    "./mdx-components.{ts,tsx}",
    "./node_modules/fumadocs-ui/dist/**/*.js",
  ],
} satisfies Config;

export default webConfig;

Current vs. Expected behavior
what I'm seeing:
TypeError: modifiers.DEFAULT is not a function

continued:
../../node_modules/.pnpm/fumadocs-twoslash@2.0.1_@types+react-dom@18.3.1_@types+react@18.3.4_fumadocs-ui@14.5.2_@types_ocxgvelh4pzbvyoit2l4ywgdye/node_modules/fumadocs-twoslash/dist/twoslash.css.webpack[javascript/auto]!=!../../node_modules/.pnpm/next@14.2.18_react-dom@18.3.1_react@18.3.1__react@18.3.1_sass@1.77.4/node_modules/next/dist/build/webpack/loaders/css-loader/src/index.js??ruleSet[1].rules[14].oneOf[12].use[2]!../../node_modules/.pnpm/next@14.2.18_react-dom@18.3.1_react@18.3.1__react@18.3.1_sass@1.77.4/node_modules/next/dist/build/webpack/loaders/postcss-loader/src/index.js??ruleSet[1].rules[14].oneOf[12].use[3]!../../node_modules/.pnpm/fumadocs-twoslash@2.0.1_@types+react-dom@18.3.1_@types+react@18.3.4_fumadocs-ui@14.5.2_@types_ocxgvelh4pzbvyoit2l4ywgdye/node_modules/fumadocs-twoslash/dist/twoslash.css

Provide environment information
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.1.0: Thu Oct 10 21:05:14 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T8103
  Available memory (MB): 16384
  Available CPU cores: 8
Binaries:
  Node: 20.16.0
  npm: 10.8.1
  Yarn: 1.22.19
  pnpm: 9.12.3
Relevant Packages:
  next: 15.0.3 // Latest available version is detected (15.0.3).
  eslint-config-next: N/A
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 4.9.5
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)
UI
Additional context
seems to be coming from here: https://github.com/fuma-nama/fumadocs/blob/f34e8956dad6017e0e6853dc23c130a564df95e3/packages/ui/src/theme/typography/index.ts#L175
I'm running this as an app in a turborepo environment

Update, on trying to remove twoslash the underlying issue is that I can't import css at all. I get a similar error when trying to import global.css or my @repo/ui/globals.css

Could you use mjs or mts for tailwind css config to ensure it's not due to ESM compatibility issues?

just supported custom typography styles via theme.extends.typography, it should fix the issue if you were using it to customise styles

Could you use mjs or mts for tailwind css config to ensure it's not due to ESM compatibility issues?

Sorry about the late reply but I ended up removing my @repo/ui components and that seemed to fix it. I'm still not sure what the root cause is

Glad it's fixed, feel free to provide a reproduction anytime so I can investigate further into the issue. Currently I believe Typography issues are fixed with the latest release, would close this for now.

just supported custom typography styles via theme.extends.typography in Tailwind CSS config, it should fix the issue if you were using it to customise styles

This works with my @repo/ui components now!

authors: Maniktherana fuma-nama

repo: fuma-nama/fumadocs


text:
default to workspace TS version in .vscode/settings.json

Add the following to .vscode/settings.json
{
  "typescript.tsdk": "node_modules/typescript/lib"
}

typescript.tsserver.pluginPaths

I don't think it'll work to force the plugin paths

Yeah, this setting has to be set personally.

authors: sam-goodwin thantos

repo: functionless/functionless-projen


text:
Hydrus stores timestamps as milliseconds

the Hydrus release last week changed the handling of timestamps, breaking DB import. I get this error:
Unable to initialize DB! SqliteError: no such column: current_files.timestamp     at Database.prepare (/app/node_modules/better-sqlite3/lib/methods/wrappers.js:5:21)     at i.<anonymous> (/build/server/helpers/dbImport/import.ts:61:31)     at Generator.next (<anonymous>)     at o (/app/server.js:229:1105)     at processTicksAndRejections (node:internal/process/task_queues:95:5) {   code: 'SQLITE_ERROR' }
I’m pretty sure the issue is here:
https://github.com/funmaker/Hybooru/blob/6ed6b1740aebc95c537b5728d2cfd46516ba7bce/server/helpers/dbImport/posts.ts#L33
The timestamp column is named timestamp_ms now, and presumably is millisecond-precision.

Fixes as of v1.11.0

authors: funmaker kylebavis

repo: funmaker/Hybooru


text:
Hawtjni plugin for gradle

It would be great to be able to use the plugin from gradle projects.
@chirino any thoughts/interest?

Sounds good. Send in a PR

authors: chirino nmittler

repo: fusesource/hawtjni


text:
Add custom winston libdef

This is the same libdef from fusion-plugin-universal-logger, but with one fix for the transports.
This is necessary otherwise we see flow errors such as:

!merge

repo: fusionjs/fusion-cli


text:
Update error handling to bubble errors that occur in reducers

Fixes #81

!merge

repo: fusionjs/fusion-rpc-redux


text:
make clean more portable

xargs -r is gnu specific and fails on bsd (macos).  Using exec is more portable.

👍

Thx

authors: aweis89 snstanton szibis

repo: futuresimple/helm-secrets


text:
Usage of @Nullable annotation

Hi,
I use your application as reference.
You/We have View Widgets  and Injected dependencies that are annotated with @Nullable.
@Nullable annotation act like in Kotlin "?". It means that we need to write use case to deal with both cases when something can be null or not. In other words its part of business logic.
Lets analyze View Widget:
 @Nullable     @BindView(id.search_view)     SearchView searchView;
If is annotated with @Nullable then probably there are some business logic regarding this widget where in some cases it can be null and in other not.
The same are with injected dependencies.
Analyzing the code we see that only case when widgets and dependencies can be null is case when something goes wrong with Butterknife and Dagger but its have nothing related to business logic.
I think that both widgets and dependencies needed to be annotated with @NonNull because there is no use case when they can be null and run specific logic.
All these @Nullable annotations make class full of "non null" checks to fix "lint" warnings.
Probably you put @Nullable instead of @NonNull to fix "lint" warning that suggest to initialize the property.
Maybe in case with generated initializations (Butterknife, Dagger ...) we no need to use @NonNull/@Nullable annotations at all.
Thanks for helping me understand!

I've also been reconsidering our rather gratuitous use of @Nullable because of exactly the reasons you have described - that @Nullable should be driven by business/API reasons rather by-product of the lifecycle and/or view binding technicalities.
If I'm not mistaken, Kotlin has lateinit and by lazy keywords which might do a better job of conveying the idea of what we are really trying to achieve. But we're not using Kotlin, at least not yet.
In any case, I would agree that it would be better if we removed @Nullable unless we consider the field to be optional. Any thoughts @tomaszpolanski ?

I've made https://github.com/futurice/freesound-android/pull/111 as an experiment

With ButterKnife bindings I find it tedious to use those nullables.
As long we make linter happy in some way, I'm fine by skipping those nullables.

Resolved via #111

repo: futurice/freesound-android


text:
Add Mindot Tour

https://twitter.com/earthtonesHQ/status/1049796749185953797
https://photos.app.goo.gl/cKy6yb4WKbBRQmKw6

✅ By submitting this issue, I have verified the following

[x] Checked to see if the issue has already been discussed before 🤔
[x] If proposing new content to be added, enough details were provided 🔍

Dear Frances,
On behalf of the Mindot Team, I would like to thank you for your amazing tour and panel for our students. The students could not stop talking about Slack. It truly was an amazing experience for them.
We truly appreciate your time and assistance and we hope you enjoyed meeting the students. To us, giving back our time and energy to impacting students and disrupt education is our number one priority.
Once again, thank you and if you ever need anything from us, please do not hesitate to reach out to us. We would be delighted to help you!
Please find attached some pictures from the visit in case you would like them for any internal newsletter and / or usage for your LinkedIn Profile highlighting your give back!
Hugs,
Natalie


text:
Out of range index error

Hi,
I think there is an "out of range IndexError" in the "bin_array" class inside coverage.py file: line 278:
self.nbins = -1 if len(nbins) == 0 else nbins[1]
I believe it should be nbins[0]. Please correct me if I'm missing something here.
Thanks

Good catch, Hodjat! You're correct about the index being incorrect. I've added a test to show the error, as well as a fix (2f6a5bd).

By the way, I'm very much open to PRs.

repo: fvutils/pyvsc


text:
Fix Compilation on ARM

It seems like -m64 is an x86 tag. See (compilation error cc: error: unrecognized command line option ‘-m64' in #40 ). This appears to be breaking ARM builds.

@LilyGinger could you add the following to external/geogram/CMakeLists.txt at line 41:
message("VORPALINE_PLATFORM: ${VORPALINE_PLATFORM}")

Hi, @fwilliams  Here is the output:
running build
running build_py
running build_ext
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Deprecation Warning at CMakeLists.txt:4 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.

Cloning into 'numpyeigen'...
HEAD is now at 4916d92... update pybind11
-- Performing Test COMPILER_SUPPORT_OPENMP
-- Performing Test COMPILER_SUPPORT_OPENMP - Success
CMake Warning (dev) at external/numpyeigen/cmake/numpyeigen.cmake:98 (set):
  Cannot set "NPE_ROOT_DIR": current scope has no parent.
Call Stack (most recent call first):
  CMakeLists.txt:21 (include)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Deprecation Warning at CMakeLists.txt:4 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.

Cloning into 'eigen'...
HEAD is now at 21ae2af... bump to 3.3.7
CMake Deprecation Warning at CMakeLists.txt:4 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.

Cloning into 'pybind11'...
Switched to a new branch 'numpy_hacks_stable'
HEAD is now at aeda673... Hacks for numpyeigen
-- pybind11 v2.9.0
-- Found PythonInterp: /usr/bin/python3 (found version "3.8.7")
-- Found PythonLibs: /usr/lib/arm-linux-gnueabihf/libpython3.8.so
-- Performing Test HAS_FLTO
-- Performing Test HAS_FLTO - Success
CMake Deprecation Warning at CMakeLists.txt:4 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.

Cloning into 'manifold'...
HEAD is now at 81fd342... Update README.md
CMake Deprecation Warning at CMakeLists.txt:4 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.

Cloning into 'embree'...
HEAD is now at 69bd4c2... regenerated documentation
-- Found Git: /usr/bin/git (found version "2.7.4")
CMake Deprecation Warning at external/embree/CMakeLists.txt:64 (cmake_policy):
  The OLD behavior for policy CMP0072 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.

-- Detecting default ISA...
-- Detected default ISA: SSE2
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
CMake Deprecation Warning at external/geogram/CMakeLists.txt:9 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.

VORPALINE_PLATFORM: Linux64-gcc-dynamic
-- Using local options file: /home/orca/zbz/point-cloud-utils/external/geogram/CMakeOptions.txt
-- Configuring build for standalone Geogram (without Vorpaline)
-- GCC version >= 4.3, activating sign conversion warnings
-- GCC version >= 4.6, activating double promotion warnings
-- Doxygen >= 1.7.0 not found, cannot generate documentation
CMake Deprecation Warning at external/geogram/doc/CMakeLists.txt:7 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.

-- Found OpenMP_C: -fopenmp (found version "4.0")
-- Found OpenMP_CXX: -fopenmp (found version "4.0")
-- Found OpenMP: TRUE (found version "4.0")
-- Found OpenMP_C: -fopenmp (found version "4.0")
-- Found OpenMP_CXX: -fopenmp (found version "4.0")
-- Configuring done
-- Generating done
-- Build files have been written to: /home/orca/zbz/point-cloud-utils/build/temp.linux-armv7l-3.8
[  0%] Building CXX object CMakeFiles/npe.dir/external/numpyeigen/src/npe_typedefs.cpp.o
[  0%] Building C object geogram/src/lib/geogram/third_party/CMakeFiles/geogram_third_party.dir/LM7/libmeshb7.c.o
cc: error: unrecognized command line option '-m64'
geogram/src/lib/geogram/third_party/CMakeFiles/geogram_third_party.dir/build.make:75: recipe for target 'geogram/src/lib/geogram/third_party/CMakeFiles/geogram_third_party.dir/LM7/libmeshb7.c.o' failed
make[2]: *** [geogram/src/lib/geogram/third_party/CMakeFiles/geogram_third_party.dir/LM7/libmeshb7.c.o] Error 1
CMakeFiles/Makefile2:716: recipe for target 'geogram/src/lib/geogram/third_party/CMakeFiles/geogram_third_party.dir/all' failed
make[1]: *** [geogram/src/lib/geogram/third_party/CMakeFiles/geogram_third_party.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
In file included from /home/orca/zbz/point-cloud-utils/external/numpyeigen/src/npe_typedefs.h:6:0,
                 from /home/orca/zbz/point-cloud-utils/external/numpyeigen/src/npe_typedefs.cpp:1:
/home/orca/zbz/point-cloud-utils/external/numpyeigen/cmake/../src/npe_sparse_array.h:17:8: warning: 'npe::sparse_array' declared with greater visibility than the type of its field 'npe::sparse_array::<anonymous>' [-Wattributes]
 struct sparse_array : pybind11::object {
        ^
/home/orca/zbz/point-cloud-utils/external/numpyeigen/cmake/../src/npe_sparse_array.h:17:8: warning: 'npe::sparse_array' declared with greater visibility than its base 'pybind11::object' [-Wattributes]
In file included from /home/orca/zbz/point-cloud-utils/external/numpyeigen/src/npe_typedefs.cpp:1:0:
/home/orca/zbz/point-cloud-utils/external/numpyeigen/src/npe_typedefs.h:18:1: error: static assertion failed: NumpyEigen Does not support 32-bit platforms
 static_assert(sizeof(long) == sizeof(long long), "NumpyEigen Does not support 32-bit platforms");
 ^
/home/orca/zbz/point-cloud-utils/external/numpyeigen/src/npe_typedefs.h:19:1: error: static assertion failed: NumpyEigen Does not support 32-bit platforms
 static_assert(sizeof(unsigned long) == sizeof(unsigned long long), "NumpyEigen Does not support 32-bit platforms");
 ^
/home/orca/zbz/point-cloud-utils/external/numpyeigen/src/npe_typedefs.h: In function 'constexpr char npe::detail::transform_typechar(char)':
/home/orca/zbz/point-cloud-utils/external/numpyeigen/src/npe_typedefs.h:281:5: error: static assertion failed: Expected sizeof(long) = sizeof(long long)
     static_assert(sizeof(long) == sizeof(long long), "Expected sizeof(long) = sizeof(long long)");
     ^
/home/orca/zbz/point-cloud-utils/external/numpyeigen/src/npe_typedefs.h:282:5: error: static assertion failed: Expected sizeof(unsigned long) = sizeof(unsigned long long)
     static_assert(sizeof(unsigned long) == sizeof(unsigned long long), "Expected sizeof(unsigned long) = sizeof(unsigned long long)");
     ^
/home/orca/zbz/point-cloud-utils/external/numpyeigen/src/npe_typedefs.h: In function 'constexpr int npe::detail::transform_typeid(int)':
/home/orca/zbz/point-cloud-utils/external/numpyeigen/src/npe_typedefs.h:341:5: error: static assertion failed: Expected sizeof(long) = sizeof(long long)
     static_assert(sizeof(long) == sizeof(long long), "Expected sizeof(long) = sizeof(long long)");
     ^
/home/orca/zbz/point-cloud-utils/external/numpyeigen/src/npe_typedefs.h:342:5: error: static assertion failed: Expected sizeof(unsigned long) = sizeof(unsigned long long)
     static_assert(sizeof(unsigned long) == sizeof(unsigned long long), "Expected sizeof(unsigned long) = sizeof(unsigned long long)");
     ^
/home/orca/zbz/point-cloud-utils/external/numpyeigen/src/npe_typedefs.cpp: In function 'int npe::detail::get_type_id(bool, char, npe::detail::StorageOrder)':
/home/orca/zbz/point-cloud-utils/external/numpyeigen/src/npe_typedefs.cpp:98:7: error: static assertion failed: Expected sizeof(long) = sizeof(long long)
       static_assert(sizeof(long) == sizeof(long long), "Expected sizeof(long) = sizeof(long long)");
       ^
/home/orca/zbz/point-cloud-utils/external/numpyeigen/src/npe_typedefs.cpp:117:7: error: static assertion failed: Expected sizeof(unsigned long) = sizeof(unsigned long long)
       static_assert(sizeof(unsigned long) == sizeof(unsigned long long), "Expected sizeof(unsigned long) = sizeof(unsigned long long)");
       ^
/home/orca/zbz/point-cloud-utils/external/numpyeigen/src/npe_typedefs.cpp:154:7: error: static assertion failed: Expected sizeof(long) = sizeof(long long)
       static_assert(sizeof(long) == sizeof(long long), "Expected sizeof(long) = sizeof(long long)");
       ^
/home/orca/zbz/point-cloud-utils/external/numpyeigen/src/npe_typedefs.cpp:173:7: error: static assertion failed: Expected sizeof(unsigned long) = sizeof(unsigned  long long)
       static_assert(sizeof(unsigned long) == sizeof(unsigned long long), "Expected sizeof(unsigned long) = sizeof(unsigned  long long)");
       ^
/home/orca/zbz/point-cloud-utils/external/numpyeigen/src/npe_typedefs.cpp:211:7: error: static assertion failed: Expected sizeof(long) = sizeof(long long)
       static_assert(sizeof(long) == sizeof(long long), "Expected sizeof(long) = sizeof(long long)");
       ^
/home/orca/zbz/point-cloud-utils/external/numpyeigen/src/npe_typedefs.cpp:230:7: error: static assertion failed: Expected sizeof(unsigned long) = sizeof(unsigned  long long)
       static_assert(sizeof(unsigned long) == sizeof(unsigned long long), "Expected sizeof(unsigned long) = sizeof(unsigned  long long)");
       ^
/home/orca/zbz/point-cloud-utils/external/numpyeigen/src/npe_typedefs.cpp:273:7: error: static assertion failed: Expected sizeof(long) = sizeof(long long)
       static_assert(sizeof(long) == sizeof(long long), "Expected sizeof(long) = sizeof(long long)");
       ^
/home/orca/zbz/point-cloud-utils/external/numpyeigen/src/npe_typedefs.cpp:292:7: error: static assertion failed: Expected sizeof(unsigned long) = sizeof(unsigned  long long)
       static_assert(sizeof(unsigned long) == sizeof(unsigned long long), "Expected sizeof(unsigned long) = sizeof(unsigned  long long)");
       ^
/home/orca/zbz/point-cloud-utils/external/numpyeigen/src/npe_typedefs.cpp:329:7: error: static assertion failed: Expected sizeof(long) = sizeof(long long)
       static_assert(sizeof(long) == sizeof(long long), "Expected sizeof(long) = sizeof(long long)");
       ^
/home/orca/zbz/point-cloud-utils/external/numpyeigen/src/npe_typedefs.cpp:348:7: error: static assertion failed: Expected sizeof(unsigned long) = sizeof(unsigned  long long)
       static_assert(sizeof(unsigned long) == sizeof(unsigned long long), "Expected sizeof(unsigned long) = sizeof(unsigned  long long)");
       ^
CMakeFiles/npe.dir/build.make:75: recipe for target 'CMakeFiles/npe.dir/external/numpyeigen/src/npe_typedefs.cpp.o' failed
make[2]: *** [CMakeFiles/npe.dir/external/numpyeigen/src/npe_typedefs.cpp.o] Error 1
CMakeFiles/Makefile2:363: recipe for target 'CMakeFiles/npe.dir/all' failed
make[1]: *** [CMakeFiles/npe.dir/all] Error 2
Makefile:165: recipe for target 'all' failed
make: *** [all] Error 2
Traceback (most recent call last):
  File "setup.py", line 116, in <module>
    main()
  File "setup.py", line 89, in main
    setuptools.setup(
  File "/usr/local/lib/python3.8/dist-packages/setuptools/__init__.py", line 153, in setup
    return distutils.core.setup(**attrs)
  File "/usr/lib/python3.8/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/usr/lib/python3.8/distutils/dist.py", line 966, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python3.8/distutils/dist.py", line 985, in run_command
    cmd_obj.run()
  File "/usr/lib/python3.8/distutils/command/build.py", line 135, in run
    self.run_command(cmd_name)
  File "/usr/lib/python3.8/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/usr/lib/python3.8/distutils/dist.py", line 985, in run_command
    cmd_obj.run()
  File "setup.py", line 39, in run
    self.build_extension(ext)
  File "setup.py", line 72, in build_extension
    subprocess.check_call(['cmake', '--build', '.'] + build_args, cwd=self.build_temp)
  File "/usr/lib/python3.8/subprocess.py", line 364, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '--build', '.', '--config', 'Release', '--', '-j2']' returned non-zero exit status 2.

Thanks @LilyGinger
Can you also add the following after that line and rerun the build:
IF(${CMAKE_SYSTEM_PROCESSOR} MATCHES "arm")
message("ON ARM CPU")
ELSE(${CMAKE_SYSTEM_PROCESSOR} MATCHES "arm")
message("NOT ON ARM CPU")
ENDIF(${CMAKE_SYSTEM_PROCESSOR} MATCHES "arm")

Hi, Here is the new output.
zbz@nvidia-desktop ~/z/point-cloud-utils (master)> python3 setup.py build
running build
running build_py
running build_ext
CMake Warning (dev) at external/numpyeigen/cmake/numpyeigen.cmake:98 (set):
  Cannot set "NPE_ROOT_DIR": current scope has no parent.
Call Stack (most recent call first):
  CMakeLists.txt:21 (include)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- pybind11 v2.9.0
-- Detecting default ISA...
-- Detected default ISA: SSE2
VORPALINE_PLATFORM: Linux64-gcc-dynamic
-- Using local options file: /home/zbz/zbz/point-cloud-utils/external/geogram/CMakeOptions.txt
-- Configuring build for standalone Geogram (without Vorpaline)
-- GCC version >= 4.3, activating sign conversion warnings
-- GCC version >= 4.6, activating double promotion warnings
-- Doxygen >= 1.7.0 not found, cannot generate documentation
-- Found OpenMP_C: -fopenmp
-- Found OpenMP_CXX: -fopenmp
-- Found OpenMP_C: -fopenmp
-- Found OpenMP_CXX: -fopenmp
-- Configuring done
-- Generating done
-- Build files have been written to: /home/zbz/zbz/point-cloud-utils/build/temp.linux-aarch64-3.6
[  1%] Built target npe
[  3%] Built target manifold
[  3%] Building C object geogram/src/lib/geogram/third_party/CMakeFiles/geogram_third_party.dir/LM7/libmeshb7.c.o
[  3%] Building CXX object embree/common/sys/CMakeFiles/sys.dir/sysinfo.cpp.o
cc: error: unrecognized command line option ‘-m64’
geogram/src/lib/geogram/third_party/CMakeFiles/geogram_third_party.dir/build.make:62: recipe for target 'geogram/src/lib/geogram/third_party/CMakeFiles/geogram_third_party.dir/LM7/libmeshb7.c.o' failed
make[2]: *** [geogram/src/lib/geogram/third_party/CMakeFiles/geogram_third_party.dir/LM7/libmeshb7.c.o] Error 1
CMakeFiles/Makefile2:780: recipe for target 'geogram/src/lib/geogram/third_party/CMakeFiles/geogram_third_party.dir/all' failed
make[1]: *** [geogram/src/lib/geogram/third_party/CMakeFiles/geogram_third_party.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
c++: error: unrecognized command line option ‘-msse2’
embree/common/sys/CMakeFiles/sys.dir/build.make:62: recipe for target 'embree/common/sys/CMakeFiles/sys.dir/sysinfo.cpp.o' failed
make[2]: *** [embree/common/sys/CMakeFiles/sys.dir/sysinfo.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
[  3%] Building CXX object embree/common/sys/CMakeFiles/sys.dir/alloc.cpp.o
c++: error: unrecognized command line option ‘-msse2’
embree/common/sys/CMakeFiles/sys.dir/build.make:86: recipe for target 'embree/common/sys/CMakeFiles/sys.dir/alloc.cpp.o' failed
make[2]: *** [embree/common/sys/CMakeFiles/sys.dir/alloc.cpp.o] Error 1
CMakeFiles/Makefile2:310: recipe for target 'embree/common/sys/CMakeFiles/sys.dir/all' failed
make[1]: *** [embree/common/sys/CMakeFiles/sys.dir/all] Error 2
Makefile:162: recipe for target 'all' failed
make: *** [all] Error 2
Traceback (most recent call last):
  File "setup.py", line 116, in <module>
    main()
  File "setup.py", line 111, in main
    test_suite="tests"
  File "/usr/local/lib/python3.6/dist-packages/setuptools/__init__.py", line 153, in setup
    return distutils.core.setup(**attrs)
  File "/usr/lib/python3.6/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/usr/lib/python3.6/distutils/dist.py", line 955, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python3.6/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/usr/lib/python3.6/distutils/command/build.py", line 135, in run
    self.run_command(cmd_name)
  File "/usr/lib/python3.6/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/usr/lib/python3.6/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "setup.py", line 39, in run
    self.build_extension(ext)
  File "setup.py", line 72, in build_extension
    subprocess.check_call(['cmake', '--build', '.'] + build_args, cwd=self.build_temp)
  File "/usr/lib/python3.6/subprocess.py", line 311, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '--build', '.', '--config', 'Release', '--', '-j2']' returned non-zero exit status 2.

@LilyGinger I think something might be amiss. Did you paste the above lines in  external/geogram/CMakeLists.txt around line 41? Your output should contain ON ARM CPU or NOT ON ARM CPU in the output. Can you run python setup.py clean before building?

Is there a solution to build on ARM systems?

From my understanding the problem comes from geogram, which (as you mentioned) has the -m64 tag that breaks the ARM build.
In the geogram repo they mention a way to make it work but I'm unsure on how to integrate it into this repository. Any suggestions?
https://github.com/alicevision/geogram/issues/19

Hi, yes it seems the problem is with geogram (geogram is also blocking builds on M1 macs).
I have a copy of geogram directly in the repo (i.e. not a CMake external project), so you can modify geogram's CMake directly to make it work. I don't have an ARM machine to test this on so I haven't done it. If you manage to get it compiling, I would love a PR. Also very happy to answer any questions/work with you to get this working!

I'm actually working on a Khadas Vim3 board (https://www.khadas.com/vim3). I will see what i can do to make it work. Any initial hints what I should look out for?

I think making a branch in the geogram cmake without the -m64 flag is a good start. Embree may also give you trouble but bumping the version should work. See the M1 Mac issue #42 which has more on that. Geogram had issues building on M1 Mac but that's just because the ifdefs for OSX assume Intel CPUs and include things like SSE headers. This shouldn't impact your case. Let me know if you run into any issues!

Geogram should indeed just have a switch for excluding the -m64 and -m32 flags on non arm builds and as you mentioned eigen is the next problem a build runs into.
I am figuring that one out now and will let you know as soon as I found something. Maybe I'll come round the corner with a PR ;P

Thanks @Layer3! Did you embree instead of Eigen?
For both @brunovollmer and @Layer3, I created an arm branch which has the latest version of embree. If you can fix geogram, you can use that as the base for your PR.

Yea @fwilliams compiling geogram isn't the big issue for me, that is easily doable by adding a little cmake switchto exclude the -m64/-m32 flags. The bigger problem is that the CortexA73 doesn't play nice with sse, so now I'm currently stuck with this.
In file included from /home/khadas/point-cloud-utils/external/igl/fast_winding_number.h:4,
                       from /home/khadas/point-cloud-utils/external/igl/signed_distance.h:14,
                       from /home/khadas/point-cloud-utils/build/temp.linux-aarch64-cpython-38/signed_distance.out.cpp:4:
      /home/khadas/point-cloud-utils/external/igl/FastWindingNumberForSoups.h:374:10: fatal error: emmintrin.h: No such file or directory
        374 | #include <emmintrin.h>
            |          ^~~~~~~~~~~~~
      compilation terminated.

Up to this point I've just been deactivating sse where I could or adjust the asm calls if I had to, but this one feels just too wrong.

Hey @fwilliams,
I managed to compile point_cloud_utils on arm now. In the end I used simde to translate the sse2 calls that are used in igl to arm compatible instructions.
I'm now running into the issue that _pcu_internal is not found when I try importing the module.
Just wondering if you got any thoughts on this.
I have all my changes for this on a fork currently.

Thanks for this, I'd love to merge these changes into the repo!
Could you create a PR with your fork? That would help me resolve your issue.

Sure, I can clean them up some more and then PR them to one of the arm branches.
Regarding the issue I still had.
I am able to manualy import _pcu_internal from the build directory, so I think the pcu should be generally good to go still and it's probably just some confusion between the build and deploy configurations.
Also I've seen that you already did some updates on the arm branches. I haven't used those as a base, so will have to merge that in first and confirm that everything still works.

Just to confirm that it runs, this is on a CortexA73
Python 3.8.1 (default, Apr 12 2022, 13:08:56)
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import point_cloud_utils
>>> import numpy as np
>>> a = np.random.rand(100, 3)
>>> b = np.random.rand(100, 3)
>>> M = point_cloud_utils.pairwise_distances(a,b)
>>> w_a = np.ones(a.shape[0])
>>> w_b = np.ones(b.shape[0])
>>> P = point_cloud_utils.sinkhorn(w_a, w_b, M, eps=1e-3)
>>> sinkhorn_dist = (M*P).sum()
>>> sinkhorn_dist
2.960956756340707

Amazing that it works!!!
I would ignore the current arm branch! I was messing around with updating embree but didn't really get anywhere. I'll delete it for now.

@fwilliams Prepared the PR, do you want to open a separate branch for that?

Hi @fwilliams, I am trying to install your repo.
But I can't install using pip and source code.
Can you make a documentation about installation for M1 mac users?
It will be useful for arm users.
Thanks a lot and have a good day :)

Hi @BupyeongHealer thanks for posting here. There's currently an open PR which fixes M1 mac compilation #55
I'm going  to try and merge this soon and cut a new release which works on M1 macs.

Good to hear that! Thanks a lot 👍

This is fixed!

Hello, just to notify that the new version  of Geogram is compatible with M1, in case it is useful to you !

authors: BrunoLevy BupyeongHealer Layer3 LilyGinger brunovollmer fwilliams

repo: fwilliams/point-cloud-utils


text:
Conformity van brug WOB

controleer de conformity van de brug WB
voor meer uitleg over meer uitleg over conformity check de epic
schrijf je bevindingen op in een rapport

[ ] Allowed character checks

[ ] Batch totals

[ ] Consistency checks

[ ] Format or picture check

[ ] Presence check

Niet meer van toepassing.

authors: dennimus kcpveen


text:
feat: fix twice trigger

Before submitting a pull request, please make sure the following is done:

You have merged in the latest changes from master.
Resolved any conflicts that may have happened from that merge.
Ensure that you have run linting locally with npm run eslint.

// eslint-disable-next-line no-unused-vars
import angular from 'angular';
// eslint-disable-next-line no-unused-vars
import app from './app/app';

const component = () => {
	// eslint-disable-next-line angular/document-service
	const element = document.createElement('div');

-	element.setAttribute('ng-app', 'appModule'); //repeat with `angular.bootstrap`, so should remove this line
	element.className = 'app';

	element.innerHTML = `
            <app></app>
      `;

	return element;
};

angular.element(() => {
	angular.bootstrap(document, ['appModule']);
});

// eslint-disable-next-line angular/document-service
document.body.appendChild(component());

#18

repo: fyodorio/ng-hotrod


text:
现在的代码可以通过input接收 *通配 来实现multiselect么

场景是我会动态获取返回的内容，内容有一定的相似性可以进行通配，手动一个个选择太多了，比较麻烦

不能，你可以通过 filter input 然后 全选

repo: fzdwx/infinite


text:
findWithin2d not working

https://github.com/fzi-forschungszentrum-informatik/Lanelet2/blob/cc815028e9faf913824b2a4aff5d111d153213ba/lanelet2_python/python_api/geometry.cpp#L35
It seems that when I call findWithin2d, I get an error. I can call findNearest fine and they are in the same file. Wondering what is up with this issue.

Maybe you should show us what the error is so we can have a better idea on how to help you.

What boost and python version are you using? I can not reproduce your problem:
>>> lanelet2.geometry.findWithin2d
  <function lanelet2.geometry.findWithin2d>

We already hat cases where Boost::Python had trouble finding the correct overload when a function is registered for many different types. We already had this problem with to2D and to3D and had to write our own overload resolution. I would not be totally surprised if this is the case here too.

Closing due to inactivity

authors: andrewyguo miropipa poggenhans


text:
RangeError (index): Invalid value: Not in inclusive range 0..9: 10

Describe the bug
when i return a list or hashMap<someEnum, somStruct> from rust code,
get this error,
flutter_rust_bridge version "=2.0.0-dev.20"
#0      _Array.[] (dart:core-patch/array.dart:10:36)
#1      RustLibApiImpl.sse_decode_stem (package:zwds/src/rust/frb_generated.dart:1060:23)
#2      RustLibApiImpl.sse_decode_house (package:zwds/src/rust/frb_generated.dart:913:20)
#3      RustLibApiImpl.sse_decode_list_house (package:zwds/src/rust/frb_generated.dart:997:16)
#4      RustLibApiImpl.sse_decode_horoscope (package:zwds/src/rust/frb_generated.dart:892:22)
#5      _SseSimpleDecoder.decodeSuccess (package:flutter_rust_bridge/src/codec/sse.dart:60:47)
#6      SimpleDecoder.decode (package:flutter_rust_bridge/src/codec/base.dart:29:16)
#7      SseCodec._decode (package:flutter_rust_bridge/src/codec/sse.dart:42:55)
#8      SseCodec.decodeObject (package:flutter_rust_bridge/src/codec/sse.dart:32:12)
<asynchronous suspension>
#9      _FutureBuilderState._subscribe.<anonymous closure> (package:flutter/src/widgets/async.dart:624:31)
<asynchronous suspension>

the struct just like this
#[derive(Debug, Clone, Default)]
pub struct House {
    pub id:String,
    pub name: HouseName, //
    pub stem:Stem,  // when decode this field got error
    pub branch:Branch,
    pub house_name:String,
    pub branch_name:String
}

#[derive(Debug, Copy, Clone, PartialEq,  IntoPrimitive, FromPrimitive,   Default)]
#[repr(u8)]
pub enum Stem
{
    #[default]
    Jia=1,
    Yi=2,
    Bing=3,
    Ding=4,
    Wu=5,
    Ji=6,
    Geng=7,
    Xin=8,
    Ren=9,
    Gui=10
}

when i use 2.0.0-dev.15, every thing goes fine
any help will be grateful
Steps to reproduce
Hint: A simple way to reproduce is to clone and modify the https://github.com/fzyzcjy/flutter_rust_bridge/tree/master/frb_example/dart_minimal example package according to your needs.

...
...
...

Logs
...

Expected behavior
No response
Generated binding code
No response
OS
window 10
Version of flutter_rust_bridge_codegen
2.0.0-dev.20
Flutter info
No response
Version of clang++
No response
Additional context
No response

thank you, let me try..

Alternatively, another workaround is temporarily try <=2.0.0-dev.19 (until I fix it)

since put full_dep: true to my flutter_rust_bridge.yaml, regenerate code  ,the error still.

thans for your time, i will Downgrade to 19 for the moment

since put full_dep: true to my flutter_rust_bridge.yaml, regenerate code ,the error still.
Hmm that's weird. I will check later.

authors: cryptoctl fzyzcjy


text:
Enhance and Complete Japanese Translations

This pull request makes minor adjustments to the Japanese translation in i18n/ja.toml. The changes include:

Revised several phrases for a more natural flow
Completed translations for previously untranslated words

These updates aim to enhance clarity and improve the overall user experience for Japanese-speaking users. Please review the changes for accuracy and naturalness. Thank you!

Hi @g1eny0ung, thanks for your feedback.
First, regarding "Flip it!", while the meaning would be understood even with a Japanese "フリップ", it might feel a bit awkward. "Flip it!" is simple English, so many Japanese people should understand it and be able to use it intuitively.
As for "About", it's an expression used on many other Japanese websites and blogs. Additionally, the direct translation "について" is typically used with a preceding word as in 「***について」so using it alone feels unnatural.

Hi @g1eny0ung, thanks for your feedback. First, regarding "Flip it!", while the meaning would be understood even with a Japanese "フリップ", it might feel a bit awkward. "Flip it!" is simple English, so many Japanese people should understand it and be able to use it intuitively. As for "About", it's an expression used on many other Japanese websites and blogs. Additionally, the direct translation "について" is typically used with a preceding word as in 「***について」so using it alone feels unnatural.

👍🏼 Thanks for the explanation, now I understand and have no problem with other translations. Thanks for the contribution! I'll merge now.


text:
Feature/nextflow temporary dag tool listing

Prototype nextflow dag and tool listing with tests
code will need to be replaced with NextFlow code after license change, but gets us something sane looking for now

Coverage increased (+0.1%) to 75.984% when pulling a2b21d1a53269de7320bb4659c4f14abb6ac707b on feature/nextflow_temporary_dag_tool_listing into d4dd5028949905272934356648cde280ee4c8cd8 on develop.

authors: coveralls denis-yuen


text:
G2P needs data driven tests

We need to add some data driven tests to ensure that we are correctly translating G2P input data into GA4GH objects.

@dcolligan I believe this was resolved back in April #1061

authors: bwalsh jeromekelleher


text:
🛑 Revista is down

In d449d0d, Revista (https://pensamientopenal.com.ar/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Revista is back up in 387a381.


text:
🛑 Revista is down

In 914959f, Revista (https://pensamientopenal.com.ar/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Revista is back up in 69f33a9.


text:
🛑 Revista is down

In 2a4f60e, Revista (https://pensamientopenal.com.ar/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Revista is back up in 37c255a.


text:
PS3 Rock Band/Guitar Hero Instruments

This includes the following instrument additions for PS3 on macOS:
-Guitar Hero: World Tour Wireless Drum Kit (03000000ba1200002001000008010000)
-Guitar Hero 5 Wireless Genericaster Guitar (03000000ba1200000001000005000000)
-The Beatles: Rock Band Wireless Drum Kit (03000000ba1200001002000000020000)
-Rock Band 1 Wireless Fender Stratocaster Guitar (03000000ba1200000002000013030000)
-The Beatles: Rock Band Wireless Hofner Bass Guitar (03000000ba1200000002000000020000)
-Roll Limitless MIDI Drum Adapter (03000000ba1200001002000000010000)
Added for Wii on macOS:
-The Beatles: Rock Band Wireless Hofner Bass Guitar (03000000ad1b00001030000000020000)
As RPCS3 for macOS cannot map SDL in the emulator and only supports controllers found on the SDL database, these are imperative to add for the growing rhythm game community. I have included all the instruments I own and will reach out to the community for more.

Thank you for this PR. I have some concerns here I will lay out for you. Broadly speaking I am conflicted on this effort, though not totally opposed to it.

This repo is intended to supplement SDL
The db is for gamepad data. While the lines are blurred between some device types, SDL has explicit handling for other joystick devices types (eg. wheels, flightsticks, simulated musical instruments) and as such gamepad handling, including mapping, is meant to omit these device types, instead handling support for them explicitly in source
Despite point #1, a number of projects that do not implement SDL evidently use this data anyway: Godot, emulators etc.

Given point #2, I think the best route would be for RPCS3 to fully implement SDL for input handling, instead of consuming this data independently, in which case any PRs related to instrument support for the RPCS3 project should be taken directly upstream to SDL.
However, I am sympathetic that this may not be a desirable effort, and since these devices are technically console gamepad analogues, am willing to accept PRs to this end if the (undesirable) alternative is further fragmentation/siloing of mapping data into individual projects as opposed to multiple projects benefiting from the consolidating effort of this db.
Please consider the following when soliciting instrument mappings from your devs/players/etc. community as an incentive to have these mappings accepted:

Encourage contributors to gather mappings on as many platforms as they have access to, regardless of what subset RPCS3 actually needs: Windows, MacOS, Linux
Encourage contributors to map the full device per the original console mapping, with an effort not to miss any secondary controls such as dpad.

Thanks

Figured I'd chime in with comments from the research and documentation I've been doing for these peripherals.
While mappings for instruments would certainly help out for general purposes, they unfortunately cannot provide complete support for all of them without additional code to handle special cases. For example:

Tilt on PS3 Guitar Hero guitars is hidden away on a vendor-defined axis and must be handled manually (unless the SDL mappings allow for mapping vendor-defined HID usages).

Pro Guitars and Pro Keyboards use a lot of axis values as bitmasks/bitfields instead of ranges, completely disregarding any semantics from XInput standards or the HID descriptor.

Guitar Hero Live guitars require a magic keep-alive packet to be sent periodically in order for all input data to be sent correctly.

(This isn't a comprehensive list, there's a lot of weird inputs and edge cases which don't usually fit into most generic input handling schemes.)
What makes things worse is that not all devices can be fully supported directly on Windows without diving down into undocumented driver interfaces (which could potentially bring about legal issues, I imagine). Notably:

Xbox 360 Pro Keyboards and Pro Guitars make use of normally-unused data bytes that lie beyond the normal XInput report. The data isn't absolutely necessary for core gameplay to work, but it's certainly a bummer that the Pro Keyboard's touchbar or the Pro Guitar's tilt aren't usable.

Xbox One instruments are just outright not supported on Windows, beyond being able to navigate menus for games/programs that implement Windows.Gaming.Input and its navigation input features. Windows.Gaming.Input.Custom has an API to create custom device types for them, which would solve this issue, however it's shimmed and doesn't publicly define everything you need.

For what it's worth though, these two cases are rather niche, and all of the other instruments can be supported without much more issue (excluding cases like Xbox 360/One instruments on Mac which require additional driver support or manual USB handling).

My initial assumption was that RCPS3 was not using SDL proper for input, but relying on this db where native support is lacking as do some other apps. This was an error on my part as it seems the software does use SDL for input.
I believe the best way forward is for any additional device supprt from non-gamepad devices to come either as direct support in RCPS3 (eg USB passthrough) or a patch to SDL directly, per point 2 of my original response and @TheNathannator's comments regarding "unmappable" features. If the RPCS3/rhythm game community decide that mappings via gamepad db are indeed the best option for particular platforms/devices as @dirkNlerxst proposes with this PR, I think it might be best for an alternative mapping db to be created speficially for this purpose (adding rhythm game instrument mappings) that RCPS3 can concatenate to this (gamepad only) db upon deployment.

After discussing further elsewhere, we've settled on leaving instruments off the gamepad db with hopes that the effort can move upstream to SDL, or if necessary, downstream to the software supporting game instrument controllers.

authors: TheNathannator dirkNlerxst offalynne

license: Zlib


text:
Add "network exists" command

Podman has support for a "network exists" command which checks if a network exists. This adds support for that command, although it does so by way of network inspect for compatibility with Docker, which does not have a standalone network exists command.
Closes #618

Thanks for doing this enhancement :) Currently all PRs are blocked on the docs CI job being broken, which I believe I have fixed in https://github.com/gabrieldemarmiesse/python-on-whales/pull/628 but this needs confirming.

repo: gabrieldemarmiesse/python-on-whales


text:
🛑 Trends is down

In 00e642b, Trends (https://trends.gab.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Trends is back up in bbdaf06 after 1 hour, 8 minutes.

repo: gadmln/gabstatus