U-Boot Command Prompt

Hi Lup, thanks for your build and it's really a nice work!
I followed your detailed README, but met problems whenever I tried to run commands in u-boot:
$setenv tftp_server <IP_ADDRESS> ; dhcp ${kernel_addr_r} ${tftp_server}:Image-sg2000 ;
tftpboot ${fdt_addr_r} ${tftp_server}:jh7110-star64-pine64.dtb ; fdt addr ${fdt_addr_r} ;
booti ${kernel_addr_r} - ${fdt_addr_r}
I am stucked at the second step：
dhcp ${kernel_addr_r} ${tftp_server}
Speed: 100, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
BOOTP broadcast 7
BOOTP broadcast 8
BOOTP broadcast 9
BOOTP broadcast 10
BOOTP broadcast 11
BOOTP broadcast 12
BOOTP broadcast 13
BOOTP broadcast 14
BOOTP broadcast 15
BOOTP broadcast 16
BOOTP broadcast 17
Retry time exceeded; starting again
And when I tried to ping the host, I got:
cv181x_c906# ping <IP_ADDRESS>
Speed: 100, full duplex
***** ERROR: `ipaddr' not set**
ping failed; host <IP_ADDRESS> is not alive
It said that 'ipaddr' not set but I did set it, and this is my environment:
cv181x_c906# printenv
arch=riscv
baudrate=115200
board=mars
board_name=mars
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootriscv64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
boot_efi_bootmgr=if fdt addr ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr;fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_syslinux_conf=extlinux/extlinux.conf
boot_targets=mmc0 dhcp pxe
bootcmd=run distro_bootcmd || run sdboot || run sdbootauto
bootcmd_dhcp=devtype=dhcp; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00027:UNDI:003000;setenv bootp_arch 0x1b;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
bootcmd_mmc0=devnum=0; run mmc_boot
bootcmd_pxe=dhcp; if pxe get; then pxe boot; fi
bootdelay=1
consoledev=ttyS0
cpu=generic
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
efi_dtb_prefixes=/ /dtb/ /dtb/current/
ethact=ethernet@4070000
fdt_addr_r=0x81200000
fdtcontroladdr=9f27f810
fdtfile=cv181x_milkv_duos_sd.dtb
fdtoverlay_addr_r=0x81300000
gatewayip=<IP_ADDRESS>
ipaddr=<IP_ADDRESS>
kernel_addr_r=0x80200000
kernel_comp_addr_r=0x81800000
kernel_comp_size=0x1000000
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi
netdev=eth0
netmask=<IP_ADDRESS>
othbootargs=earlycon=sbi riscv.fwsz=0x80000   loglevel=9
pxefile_addr_r=0x81400000
ramdisk_addr_r=0x84000000
root=root=/dev/mmcblk0p2 rootwait rw
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done; setenv devplist
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;run boot_efi_bootmgr;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootriscv64.efi; then echo Found EFI removable media binary efi/boot/bootriscv64.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Found ${prefix}${boot_syslinux_conf}; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scriptaddr=0x81500000
sdboot=setenv bootargs ${reserved_mem} ${root} ${mtdparts} console=$consoledev,$baudrate $othbootargs;echo Boot from SD dev ${sddev} ...;mmc dev ${sddev} && fatload mmc ${sddev} ${uImage_addr} boot.sd;if test $? -eq 0; then bootm ${uImage_addr}#config-cv181x_milkv_duos_sd;fi;
sdbootauto=cvi_sd_boot;setenv bootargs ${reserved_mem} ${root} ${mtdparts} console=$consoledev,$baudrate $othbootargs;echo Boot from SD dev ${sddev} auto ...;mmc dev ${sddev} && fatload mmc ${sddev} ${uImage_addr} boot.sd;if test $? -eq 0; then bootm ${uImage_addr}#config-cv181x_milkv_duos_sd;fi;
sddev=0
serverip=<IP_ADDRESS>
stderr=serial
stdin=serial
stdout=serial
tftp_server=<IP_ADDRESS>
uImage_addr=0x81800000
update_addr=0x9fe00000
vendor=cvitek
Environment size: 4378/131068 bytes.
where <IP_ADDRESS> is the Ipv4 addr of my pc and <IP_ADDRESS> is the ipaddr I set manually in u-boot.
I can successfully ping the board from my host when i am on the board terminal. I am really confused and wonder if you could offer some suggestions?
Thanks!

Hi: Thank you so much for testing this :-) Sorry I'm cleaning up the instructions, please bear with me, the latest steps are here: https://github.com/lupyuen/lupyuen.github.io/blob/master/src/sg2000.md#boot-nuttx-over-tftp
I see that you're having problems with this:
## Set the U-Boot TFTP Server
## TODO: Change to your TFTP Server
setenv tftp_server <IP_ADDRESS>

## Fetch the IP Address over DHCP
## Load the NuttX Image from TFTP Server
## kernel_addr_r=0x80200000
dhcp ${kernel_addr_r} ${tftp_server}:Image-sg2000

I understand that you're using Static IP Addresses, not DHCP Dynamic IP Addresses? Maybe that's why the dhcp command is failing, it couldn't get an IP Address from the DHCP Server.
Wonder if you could try this? It might work with the Static IP Address:
## Load the NuttX Image from TFTP Server
## kernel_addr_r=0x80200000
tftpboot ${kernel_addr_r} ${tftp_server}:Image-sg2000

Please lemme know what happens. Thanks! :-)

Thanks so much for your reply!!!!
I followed your new instruction and this command worked for me!
bootcmd_tftp=tftpboot ${kernel_addr_r} ${tftp_server}:Image-sg2000 ; tftpboot ${fdt_addr_r} ${tftp_server}:jh7110-star64-pine64.dtb ; fdt addr ${fdt_addr_r} ; booti ${kernel_addr_r} - ${fdt_addr_r}
I saw the '123' printed and  entered the NuttX terminal. Great. But I have come up some new questions (sorry I'm new to this field..):

I think I only boot a bit now and I'm not sure how to fix the NuttX drive on PLIC: link. My understand is to rebuild the NuttX image using the right config, is that correct?
For the incomplete version of NuttX, every time I run 'exit', it gets stuck:
`
nsh> exit
posix_spawn: pid=0xc0202968 path=exit file_actions=0xc0202970 attr=0xc0202978 argv=0xc0202a18
exec_internal: ERROR: Failed to load program 'exit': -2
nxposix_spawn_exec: ERROR: exec failed: 2
nxtask_exit: /system/bin/init pid=3,TCB=0x8040b730

`
3.  If we set auto-boot the NuttX, how do we switch to this system after we're on the board terminal?
Hope my silly questions will not bother you and thanks in advance!

That's super awesome, thank you so much! :-)

I think I only boot a bit now and I'm not sure how to fix the NuttX drive on PLIC: link. My understand is to rebuild the NuttX image using the right config, is that correct?

No worries, the PLIC fixes have already been added to the sg2000 branch. Here's everything that we have fixed in the branch: https://github.com/lupyuen2/wip-nuttx/commits/sg2000/?author=lupyuen

2. For the incomplete version of NuttX, every time I run 'exit', it gets stuck:

Yep I think exit won't work on NuttX SG2000, since it doesn't know how to Shutdown or Reboot :-)

If we set auto-boot the NuttX, how do we switch to this system after we're on the board terminal?

If we follow the instructions here: https://github.com/lupyuen/lupyuen.github.io/blob/master/src/sg2000.md#boot-nuttx-over-tftp
## Add the Boot Command for TFTP
setenv bootcmd_tftp 'dhcp ${kernel_addr_r} ${tftp_server}:Image-sg2000 ; tftpboot ${fdt_addr_r} ${tftp_server}:jh7110-star64-pine64.dtb ; fdt addr ${fdt_addr_r} ; booti ${kernel_addr_r} - ${fdt_addr_r}'

## Save it for future reboots
saveenv

## Test the Boot Command for TFTP, then reboot
run bootcmd_tftp

## Remember the Original Boot Targets: `mmc0 dhcp pxe`
setenv orig_boot_targets "$boot_targets"

## Prepend TFTP to the Boot Targets: `tftp mmc0 dhcp pxe`
setenv boot_targets "tftp $boot_targets"

## Save it for future reboots
saveenv

Note that we save the Original Boot Targets: mmc0 dhcp pxe. So to undo the auto-boot:

Power up SG2000 and press Enter until the U-Boot Prompt appears

Restore the Original Boot Targets:
setenv boot_targets "$orig_boot_targets"

## Or This:
## setenv boot_targets "mmc0 dhcp pxe"

Save the U-Boot Settings:
saveenv

Hope this makes sense :-)

Thanks again for being my very first tester for NuttX on SG2000, I really appreciate your feedback! :-)
This weekend I'll publish my article on NuttX for SG2000. Also I'll have a quick Q&A on SG2000 at the Apache NuttX International Workshop (free to join online). Stay tuned! :-)


Calling a setState function inside of useGesture can result in unexpected behavior

Describe the bug
Calling a setState function inside of useGesture can result in unexpected behavior
Sandbox or Video
https://codesandbox.io/s/musing-lumiere-oxjo6?file=/src/App.js
In this example, as the user drags on the red square, dragCount goes from zero to 2 but rarely gets to 4, and then goes back to 2. Moving let count = 0 on line 7 somewhere outside of App() fixes the issue
Information:

React Use Gesture version: 9.1.3

Checklist:

[x] I've read the documentation.
[x] If this is an issue with drag, I've tried setting touch-action: none to the draggable element.

I'm not sure what you're trying to do here. count gets reassigned to 0 on every render and that's expected. Also setting state is not synchronous in React.
Closing this as this seems like a React specific question rather than anything else, unless I'm missing something.

You are right, it also happens onCLick. not a use-gesture issue. Sorry


Add posting to feed

This creates a space to create a post on the feed (the one on user page is still there, as in Facebook).
This can be tested by entering the Feed, posting something and then going to<EMAIL_ADDRESS>and seeing the post there.
The UI is horrible in this branch but when styling is merged everything will be fine :see_no_evil:

Looks good!


pointing to new PR for adding test vectors for select credentials

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 90.81%. Comparing base (1d59f71) to head (24b8397).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #510   +/-   ##
=======================================
  Coverage   90.81%   90.81%
=======================================
  Files         116      116
  Lines       29442    29442
  Branches     2156     2156
=======================================
  Hits        26739    26739
  Misses       2668     2668
  Partials       35       35

Components
Coverage Δ

agent
79.90% <ø> (ø)

api
97.92% <ø> (ø)

common
98.68% <ø> (ø)

credentials
95.26% <ø> (ø)

crypto
93.81% <ø> (ø)

dids
97.66% <ø> (ø)

identity-agent
96.70% <ø> (ø)

crypto-aws-kms
100.00% <ø> (ø)

proxy-agent
96.70% <ø> (ø)

user-agent
96.70% <ø> (ø)


Added support for signer alternatives

We are interested in using flask-session as our session system but noticed a lack of support for a SHA256 HMAC. In the past, I have been informed that this is stronger than the current default of a SHA1 HMAC (mostly due to length -- SHA1 is 160 bits, SHA256 is 256 bits).
https://en.wikipedia.org/wiki/Hash-based_message_authentication_code#Security
This PR adds backwards compatible support to opt in to using a SHA256 HMAC. In this PR:

Added test to verify HMAC exists in SHA1 variant
Added test for verifying SHA256 HMAC provides a longer HMAC
Added collection of various signers
Added signer_type option to all Session classes

Is there anything blocking this PR outside of merge conflicts?

Maybe we should add support for customizing a signer, which will make everyone happy.  We can provide a config key SESSION_SIGNER, you can pass in any signer instance you want.

Could you provide a more detailed example of what using that code would look like?

app.config['SESSION_SIGNER'] = hmac_sha256_signer

While that works, I would be opposed to everyone rewriting/reimplementing the same SHA256 signer. As with anything related to security, the algorithm can be great but someone can mess up implementation and ruin it (e.g. what if someone forgets the salt).

We ship with the default one, mostly people wouldn't change it.  If anyone does, there are endless possible demands, we cannot ship all of them, someone who changes the default behavior should be aware of what exactly he is doing.

While I understand the concern for maintenance, it's pretty irresponsible for something as sensitive as handling user sessions. If someone can forge someone else's user session, then they have full access as that user. Can you elaborate on what your main concern is?

There is no concern at all.  Your solution solves your problem, not everyone's problem, it is that simple.

Right but it sets up a framework for everyone to reuse signers. I imagine that someone in the future might want sha512 and this would allow for them to reuse that code by adding yet another function.
On the other hand, I don't foresee anyone ever wanting to roll their own signer fully as that violates the rule of not implementing custom security solutions.

We can add one config SESSION_SIGNER_PARAMS, which should be the all kwargs that itsdangerous.Signer takes, then we check it and make sure every param is passed in. On the one hand, you can customize anything you want for any reason, on the other, everyone can use their own salt.

That seems more restricting than the originally proposed SESSION_SIGNER parameter itself. The concept of having multiple built-in options and a custom SESSION_SIGNER override aren't mutually exclusive. How about supporting both a SESSION_SIGNER_TYPE (this PR) and SESSION_SIGNER (which fully overrides the signer)?

Intent is to deprecate signer from 0.7.0 #212. The relevant entropy should be provided by the session identifier length. Flask-session is for only serverside sessions so I can see no point in signing only the session id and expiry, that is effectively just making the sid longer, which can be ajusted in SESSION_SID_LENGTH
If anyone can put forward an alternative case I would like to hear it

Closing due to no activity and deprecation of signer.


[5.7] Make use of a test listener

Use a test listener instead of m::close() in every test

Wasn't this already shot down in #25972?

@svenluijten It was because the PR was doing to much (and got too big), so I split it up into multiple parts

👎  the implicitness is confusing.
The next developer comes around and tries to add them in addition to the listener because "he doesn't see where it's called" (although it works).
I think a single-top level tearDown would be more clear instead of all the ones but I assume there's reason we don't have this?

I could create a new parent TestClass for all tests too if that solution seems the better way

The tests are fine.


MongoDB is not required anymore to run tests

I was able to run tests without having MongoDB server running in my system. So I guess it is not required anymore. Or am I missing something?

Hello, @guigs thanks for your pull request.
You're right, if you run rake test the tests will run only for active_record. You can see in the output which orm is being used for the tests:
> rake test
==> Devise.orm = :active_record

But, in order to run the tests for all the environments, a mongodb instance is needed. It is possible to switch to mongoid by setting the DEVISE_ORM variable:
> DEVISE_ORM=mongoid rake test
==> Devise.orm = :mongoid

We're going to update the readme with more details of how to run our test suite - including how to switch rails/ruby versions too, so I will close this one.
Thanks again!


Add initial support for hppa-unknown-linux-gnu

This is the followup pull-request from:
https://github.com/rust-lang/libc/pull/3032

@bors r+

:pushpin: Commit 386afa64aae39c4fcf9da241f58b5fbefad1e383 has been approved by JohnTitor
It is now in the queue for this repository.

:hourglass: Testing commit 386afa64aae39c4fcf9da241f58b5fbefad1e383 with merge d361e08750c8a8c24cd727a9bfd1c77e2befacc7...

:sunny: Test successful - checks-actions, checks-cirrus-freebsd-13, checks-cirrus-freebsd-14
Approved by: JohnTitor
Pushing d361e08750c8a8c24cd727a9bfd1c77e2befacc7 to main...

:eyes: Test was successful, but fast-forwarding failed: 422 Changes must be made through the merge queue

I guess, we could start sending such PRs for alpha and sh4 as well. No need to do it for ia64 which has already been removed from the kernel and glibc as it's on its way out.

Oh, sorry I thought this target had been already added but seems not.
We have to revert this to make CI green, could you re-submit this once the target is added on the rustc?


Fix/update dependencies and add test to verify correct behaviour

Coverage remained the same at 93.469% when pulling 34624045f0f93134514dff0385a7b50a3872c019 on fix/update-dependencies into fd985f0cf497fc08488ea3e23889a111def58709 on master.

Coverage remained the same at 93.469% when pulling 34624045f0f93134514dff0385a7b50a3872c019 on fix/update-dependencies into fd985f0cf497fc08488ea3e23889a111def58709 on master.

@leonardoanalista I added this as a "fix" to trigger the version change. The most important change is moving "semantic-release" from a dependency (which is incorrect) to a dev-dependency.


Generate C# gRPC services as interfaces with C# 8 default interface implementations

Please read #14213
gRPC services deliberately compile to abstract base classes instead of interfaces, because classes implementing these interfaces do not compile anymore when new methods are added to the interface but not to the class.
However, C# 8 added "Default Interface Methods", which should solve these issues. This new feature should be opt-in with a new command-line argument to protoc.exe because C# 8 requires .NET Core 3.0.

Can someone tell me why it is so bad to "break the build" when new methods are added to the protocol?
When the proto file is updated with a new method, I want my build to break!  I want the compiler to tell me what methods I need to add!  I don't want to find them manually.
I don't want stubs which throw an "Unimplemented" exception.  I want them to be abstract methods (or interfaces) so the project won't compile until I implement the new methods.
Can we add a setting or command-line argument to make this happen?

The idea is that grpc + protobuf services are supposed to be backwards compatible, so adding a new method (which is an allowed action in terms of backwards compatibility) should not break the existing implementation (not even the build, because the assumption is that the old version of the service will still work perfectly fine - if that's not the case, you shouldn't be adding a new method to an existing service at all).
For this reason, we cannot implement what you requested (definitely not before we release a new major version and we're not planning on that any time soon).

Bottom line is I think there should be some automated tool that tells me, "Your C# server doesn't implement the following methods from this proto file. They will return unimplemented exceptions. You may want to add them."
The fact that there is no tool that can do this is, to me, crazy.
It could be a separate tool, called grpcaudit or grpclint or something. But in a compiled language, it would be natural for the compiler to do it via compilation errors or compilation warnings. I'm not asking you to change it for everyone. I'm just wishing there was a command-line switch to do it for those who opt in.
Is it possible to add a command-line switch for just the C# codegen? Can you tell me where in the code I might get started? I'm fine to fork...

@barcoders  note that such tool can be written in ~15lines of reflection code (you're basically looking for methods of a base class that haven't been overriden, pretty trivial) and you can include it in your unit tests.
We are not planning to include a command line switch for the behavior - the bar for adding a command line switch is much higher (if we added a command line switch for every feature request, we would have 1000 switches by now).


[Web Components | Lit] Investigate upgrade to Lit 2.x

The problem
Blocked by https://github.com/carbon-design-system/carbon-for-ibm-dotcom/issues/9767
Carbon Web Components is currently running on v1.x of lit-element / lit-html. This is one of the fundamental libraries used for rendering web components within this repository.
The solution
Investigate the level of effort for upgrading carbon-web-components to Lit 2.x.
Additional information

Investigation should consider users that are currently on lit-html/lit-element, and if there is any messaging necessary to have users upgrade to lit 2.
Corresponding upgrade issue for carbon-web-components: https://github.com/carbon-design-system/carbon-web-components/issues/657
Upgrade documentation: https://lit.dev/docs/releases/upgrade/
Additional information regarding the update is captured in this issue.

Will hold on this for now, investigation began with carbon-web-components and found that there is a directive that we are waiting on, more details at https://github.com/carbon-design-system/carbon-web-components/issues/657.

There are any ETA to migrate carbon-web-components to Lit v2? Thanks!

Any news here?
It's been almost a year since Lit v2 came out.
Thanks!

There is a new version 2.3 that prevents errors with windows not defined while using it with SSR in Node.
We are working with that versión, and it will be very useful to have it updated.

Has there been any progress one this? my team ran into an issue today where we are trying to access a web component built with carbon via a CDN but the import failed because the CDN requires v2

This is blocking some things in qiskit.org. It would be great to have bump soon :)

@jeffchew more good news!
<EMAIL_ADDRESS>just released with spread, spreadEvents, and spreadProps directives!
https://github.com/open-wc/open-wc/releases/tag/%40open-wc/lit-helpers%400.5.0

To update this issue a bit, it is being worked on!

https://github.com/carbon-design-system/carbon-for-ibm-dotcom/pull/9905
https://github.com/carbon-design-system/carbon-for-ibm-dotcom/pull/9958

Another related issue:

https://github.com/carbon-design-system/carbon-for-ibm-dotcom/issues/9750

Just want to say I appreciate so much the constant check-ins from @abdonrd, and much love to everyone on the team for all the work that has gone into building out Carbon. I'm currently using the lit alpha release and for my limited use case it's working perfectly. I haven't tried using the more complex components like data table, but it's probably better to wait a bit in case another alpha version is released.

Just want to say I appreciate so much the constant check-ins from @abdonrd, and much love to everyone on the team for all the work that has gone into building out Carbon. I'm currently using the lit alpha release and for my limited use case it's working perfectly. I haven't tried using the more complex components like data table, but it's probably better to wait a bit in case another alpha version is released.

I concur and thank you @abdonrd for staying on top of this (us!). Work is currently in flight to also upgrade Carbon Web Components to Carbon v11, which in of itself will also bring some pretty great upgrades there. From there, we should be seeing an initial v2.0.0 beta (and release candidates).
Apologies for the radio silence on this and the changing of dates, @kennylam and team will provide an updated timeline hopefully soon, but we also plan on including a sync of features between Carbon Web Components and Carbon React shortly after, so the team definitely has its work cut out for it!
cc: @annawen1 @emyarod @IgnacioBecerra @ariellalgilmore @ljcarot @jeanservaas

Thanks @jeffchew! I hope it will be soon! 🤞

Related PR about the update to Carbon v11:

https://github.com/carbon-design-system/carbon-for-ibm-dotcom/pull/10196

@jeffchew closed with the new release?
https://github.com/carbon-design-system/carbon-for-ibm-dotcom/releases/tag/%40carbon/web-components%402.0.0


Delete wallet command

Fixes #125.
For reviewers: should any of the paths out of this command have a non-zero exit code?

oh hmm, looks like there's a conflict


Checking the length of the field before trying to access the content

Checking the length of the field before trying to access the content as this is causing a crash when the first character is # without any subsequent characters.
Fix for #53

Coverage remained the same at 92.073% when pulling d8644af0a695074a1004b687fadcea72f1abd166 on ageekymonk:master into 098da33fde5f9220736531b3cb26a2dec86a8367 on chaseadamsio:master.

😅 thanks.


pypi install - missing submodules and data files

I suspect something wrong with the setup.py,
Probably the data file packaging is wrong, as well as the sub-module inclusion,
I recommend looking at https://github.com/masci/pypi-example for reference,
data files may need to use lookups like http://stackoverflow.com/a/5899643/1695680

Program installed like:
mkdir ~/opt; cd ~/opt
python3 -m venv suplemon
./suplmon/bin/pip install suplemon

Version:
~/opt/suplemon/bin/suplemon --version
0.1.50

Trying to launch the program yeilds:
2016-03-17 12:33:27,434 - root - DEBUG - Starting Suplemon...
2016-03-17 12:33:27,434 - suplemon.config - ERROR - Failed to load default config file '/home/me/opt/suplemon/lib/python3.4/site-packages/suplemon/config/defaults.json'!

The "config", "linelight", "modules", and "themes" directories in ~/opt/suplemon/lib/python3.4/site-packages/suplemon/ don't exist, and I didn't see them anywhere in the install.

Oh no, that's unfortunate. I actually seem to have the same problem. I'll get this fixed asap.

@richrd I recently had a similar issue in flake8-quotes. Here's how I reproduced the error there:
# Create temporary flake8-quotes install
mkvirtualenv flake8-quotes
git checkout master

# Build `sdist` file as we do in `release.sh`
python setup.py sdist

# Navigate to parent directory to assure no issues
cd ..

# Install distribution file
pip install flake8_quotes/dist/flake8-quotes-0.2.3.tar.gz

# Verify error is reproduced
flake8 flake8_quotes/

# Try/rinse/repeat with different edits and recompiles

I actually had the same problem even without virtualenv. It was apparently due to sdist not including the package files specified in setup.py (in package_data). I seem to have it solved by adding the files to MANIFEST.in. I've done this in #134 and hope to release soon.

The virtualenv is mostly there to prevent contaminating the global install. Glad to hear the issue has been resolved =)

Fixed in the new release v0.1.51, hope it works for you now.


[Feature]  Add persian language support

Thanks for the PR. You've did a great job in also adding to the readme and making my job easier. Appreciated!


BUG: RegularGridInterpolator on dataset with nans returns unexpected nans

Describe your issue.
Edit: dug a bit deeper and updated the issue from interpn to RegularGridInterpolator. Also, the interpolation issue can also be shown when using an array with two instead of three dimensions, so this was simplified.
A few months ago when scipy 1.10.0 was release I noticed changed and unexpected behaviour with xarray interpolation when interpolating to a new dimension. Relevant issues are https://github.com/Deltares/dfm_tools/issues/287 and https://github.com/pydata/xarray/issues/7701. These issues were temporarily fixed by installing scipy<1.10.0. However, upon creating this scipy issue, I noticed that the scipy-only testcase below behaves the same in both scipy 1.9.3 and scipy 1.11.3. This scipy issue seems therefore version independent.
I found out that xarray used scipy.interpolate.RegularGridInterpolator in the issues above and I could reproduce the unexpected case in a scipy-only testcase. When interpolating on a dataset that contains some nans in this case in cells that are below the ocean bottom, RegularGridInterpolator returns too much nans. The reproducible code prints this, so we see a difference between the amount of returned (interpolated) and expected nans:
point_idx 0
sp_interp   [35.82568 35.80584      nan      nan      nan]
sp_expected [35.82568  35.80584  35.789055       nan       nan]
point_idx 1
sp_interp   [35.824154 35.810417       nan       nan       nan]
sp_expected [35.824154 35.810417 35.796684       nan       nan]
point_idx 2
sp_interp   [35.824154       nan       nan       nan       nan]
sp_expected [35.824154 35.813473       nan       nan       nan]

I understand that when interpolating to points in between the lat/lon coords there will be effects from neighboring nans, which is probably also the case when interpolating to existing points as in the example below. However, I would still expect at least one less nan-value in all cases. When using method='nearest' I do get the amount of nans that I expect, but I prefer linear interpolation.
Reproducing Code Example
import numpy as np
from scipy.interpolate import RegularGridInterpolator

so_np = np.array([[35.82568 , 35.824154, 35.824154],
                  [35.80584 , 35.810417, 35.813473],
                  [35.789055, 35.796684,    np.nan],
                  [   np.nan,    np.nan,    np.nan],
                  [   np.nan,    np.nan,    np.nan]])
depths = [-1,-2,-3,-4,-5]
lons = [-9.6, -9.5, -9.4]

for point_idx in range(3):

    x_sel = lons[point_idx]

    points = (depths,lons)
    values = so_np
    xi = (depths,x_sel)
    sp_interp_pre = RegularGridInterpolator(points, values, method="linear")
    sp_interp = sp_interp_pre(xi, method='linear')

    sp_expected = so_np[:,point_idx]
    print('point_idx', point_idx)
    print('sp_interp  ', sp_interp)
    print('sp_expected', sp_expected)

    # assert (np.isnan(sp_interp) == np.isnan(sp_expected)).all()

Error message
None

SciPy/NumPy/Python version and system information
1.9.3 1.24.4 sys.version_info(major=3, minor=9, micro=16, releaselevel='final', serial=0)
blas_mkl_info:
  NOT AVAILABLE
blis_info:
  NOT AVAILABLE
openblas_info:
    library_dirs = ['D:\\a\\1\\s\\numpy\\build\\openblas_info']
    libraries = ['openblas_info']
    language = f77
    define_macros = [('HAVE_CBLAS', None)]
blas_opt_info:
    library_dirs = ['D:\\a\\1\\s\\numpy\\build\\openblas_info']
    libraries = ['openblas_info']
    language = f77
    define_macros = [('HAVE_CBLAS', None)]
lapack_mkl_info:
  NOT AVAILABLE
openblas_lapack_info:
    library_dirs = ['D:\\a\\1\\s\\numpy\\build\\openblas_lapack_info']
    libraries = ['openblas_lapack_info']
    language = f77
    define_macros = [('HAVE_CBLAS', None)]
lapack_opt_info:
    library_dirs = ['D:\\a\\1\\s\\numpy\\build\\openblas_lapack_info']
    libraries = ['openblas_lapack_info']
    language = f77
    define_macros = [('HAVE_CBLAS', None)]

I noticed this issue cannot be reproduced with the newest scipy version (1.11.3). This is odd, since I used the old scipy version (1.9.3) to avoid these interpolation issues when interpolating an xarray DataArray to a new dimension. Installing a newer scipy version messed up the interpolation. When looking at the plain scipy case the 1.9.3 version gives unexpected results, but 1.11.3 gives the expected behaviour. I am a bit lost here.

So the issue is not present in scipy 1.11?
It seems to me this is a duplicate of https://github.com/scipy/scipy/issues/19277 and https://github.com/scipy/scipy/issues/11381 --- the latter has a discussion of why we may not be able to meet specific expectations about nans.

Yes and no. The way I described the problem indeed made the issue duplicate to the issues you linked. However, I was quite sure I was not yet at the bottom of this. The initial problem occurred only when interpolating with xarray to a new dimension, created with the interpolation process, the linked xarray issue explains that (https://github.com/pydata/xarray/issues/7701). It did not occur when interpolating to the same values but to existing dimensions. Also, this happened only with scipy>=1.10.0 and it was not a problem with scipy 1.9.3 yet. I discovered that when using xarray to interpolate to existing dimensions, interp1d is used (once for each dimension). When (linearly) interpolating to a new dimension with xarray, interpn/RegularGridInterpolator is used. I noticed quite a difference in RegularGridInterpolator between versions 1.9.3 and the newest 1.11.3 release, probably for the better since as I said my example above results in expected values in 1.11.3 and not in 1.9.3. So there was a discrepancy, in xarray the results worsened with the scipy update and in scipy the results improved.
I noticed the RegularGridInterpolator updates were also about the ordering of dimensions (ascending vs descending). Therefore I tested with both ascending and descending first dimension (depth in this case). This should not make any difference since I am interpolating to all depths, in the same order as in the input array. However, I did see different behaviour between ascending and descending depth values. This is a reproducible example:
import numpy as np
from scipy.interpolate import RegularGridInterpolator

so_np = np.array([[35.82568 , 35.824154, 35.824154],
                  [35.80584 , 35.810417, 35.813473],
                  [35.789055, 35.796684,    np.nan],
                  [   np.nan,    np.nan,    np.nan],
                  [   np.nan,    np.nan,    np.nan]])

depths_asc = np.array([1,2,3,4,5])
lons = np.array([9.4, 9.5, 9.6])

for point_idx in range(3):
    print()
    print('point_idx', point_idx)
    for depths_dir in ['ascending ','descending']:
        if depths_dir=='ascending ':
            depths = depths_asc
        else:
            depths = depths_asc[::-1]

        x_sel = lons[point_idx]

        points = (depths,lons)
        values = so_np
        xi = (depths,x_sel)
        sp_interp_pre = RegularGridInterpolator(points, values, method="linear")
        sp_interp = sp_interp_pre(xi)

        print(f'sp_interp depths {depths_dir}', sp_interp)

Results in the following output:
point_idx 0
sp_interp depths ascending  [35.82568 35.80584      nan      nan      nan]
sp_interp depths descending [35.82568  35.80584  35.789055       nan       nan]

point_idx 1
sp_interp depths ascending  [35.824154       nan       nan       nan       nan]
sp_interp depths descending [35.824154 35.810417       nan       nan       nan]

point_idx 2
sp_interp depths ascending  [35.824154       nan       nan       nan       nan]
sp_interp depths descending [35.824154 35.813473       nan       nan       nan]

This is probably because of the same reason as you mention in the issues that you linked in your comment. I also ran the reproducible example with scipy 1.9.3. What I found was really explanatory for the confusion this issue caused with me. The results are very similar, but in this case, the ascending array returns more valid values (less nans), instead of the other way round:
point_idx 0
sp_interp depths ascending  [35.82568  35.80584  35.789055       nan       nan]
sp_interp depths descending [35.82568 35.80584      nan      nan      nan]

point_idx 1
sp_interp depths ascending  [35.824154 35.810417 35.796684       nan       nan]
sp_interp depths descending [35.824154 35.810417       nan       nan       nan]

point_idx 2
sp_interp depths ascending  [35.824154 35.813473       nan       nan       nan]
sp_interp depths descending [35.824154       nan       nan       nan       nan]

@ev-br: What I noticed is that when using interpn with xarray the ordering of the dimension of the input array does not matter for the outcome. So the above behaviour is corrected for I guess. However, it might explain the difference in xarray behaviour that I saw. I am curious if you indeed would say the above is expected/desired behaviour. If so, this issue can also be closed.

Let's fix some boundary conditions first:

the behavior with nans in undefined. The dependence on the scipy version you mention is an accident of internal refactorings. If those made it closer to a "good" result in your specific case, great. But that was not a goal, and it's not that some misbehavior was corrected, and it may well get "worse" with a next refactor.
Not sure what xarray does and it's downstream from scipy. If there's something to fix there, I'd be happy to review the scipy usage, feel free to ping me.
Using interp1d is almost always suboptimal, so maybe they want to fix that.

Now, RGI indeed had several improvements between versions 1.9.x and current 1.11.x, so what you observe is a byproduct of these. There are more tweaks in the pipeline.
All that said, I'd note that this issue with nans pops up somewhat regularly.
We could probably entertain tightening the contract at exact equality: in 1D it would amount to having a pair of points, (x1, y1) and (x2, nan); currently y(x1) is likely a nan; we can consider making a change to make sure that y(x1) = y1.
This would need a champion. We'd need to see that

it is done consistently for various 1D and N-D interpolators in scipy.interpolate;
performance hit is small;
the code complexity does not significantly increase

Somebody would need to make the case so that we can evaluate the above points and make the decision (which can still be a "thanks but no thanks").

That would be a great improvement I think, but not one that I would be able to build. Would you like to keep the issue open for this potential new implementation or should it be closed since the behavior that I marked as a bug is actually expected?


docs(storybook): 📝 update i18n

:tada: This PR is included in version 2.0.0-beta.1 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Improve several Read methods on ZipFile

This notably optimizes the common zip_file.read_to_end(&mut buf) case.

This repo is no longer maintained, so I've replaced this PR with https://github.com/zip-rs/zip2/pull/45.


Add "Issue Closer Bot"

https://github.com/twbs/no-carrier
Bootstrap's bot: https://github.com/twbs-closer

NO CARRIER is a tool to auto-close old GitHub issues that were abandoned by their reporter, which is to say that we were waiting for a response from the reporter but never got a response in a reasonable amount of time.

Example:

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/25486570-add-issue-closer-bot?utm_campaign=plugin&utm_content=tracker%2F281640&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F281640&utm_medium=issues&utm_source=github).

What's the simplest way to set this up (I'm not familiar with any of this stuff)? Something like heroku? @cvrebert

You just need something that supports Java 8 and lets you run a daily cronjob (or equivalent). (No Carrier isn't a daemon.) I'm not familiar enough with Heroku to say whether it'd be suitable.
We happen to run Bootstrap's No Carrier instance on the cheapest DigitalOcean VM (and we have other stuff also running on that same VM).

Would be nice to start it on Heroku, it support java 8, but it's not so easy to make daily cron runs there, even with https://addons.heroku.com/temporize
Feels like it needs some help to make it work. I'm not familiar with Scala ;-( Guess it's much easier to run on some VM.

Looks like there's this on heroku https://devcenter.heroku.com/articles/scheduler - if there is a way to run the jar on heroku through a that/cron..

I've did a try and got this error:
2015-08-08 17:29:10,653 [ERROR] com.jcabi.aspects.aj.MethodValidator - JSR-303 validator failed to initialize: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath. (see http://aspects.jcabi.com/jsr-303.html)

What I did:

made a heroku app with stub java app (it let's me to use java 8)
added github user credentials to env
downloaded and pushed no-carrier.jar to the heroku git repo
made a simple script to run java -jar no-carrier.jar jscs-dev/node-jscs "awaiting reply" 14 under the ./cron.daily.sh
ran heroku run ./cron.daily.sh

@zxqfox That error is non-fatal and can be safely ignored.

Great! It means that it works with free Heroku app ;-) Should I write a recipe?

If you add it to the wiki, I'd be happy to add a link in the README :-)

@cvrebert https://github.com/twbs/no-carrier/wiki Hope I didn't failed there ;-)

Looks good :-) I tweaked the phrasing a little and added the README link.
I'd also love to add JSCS to the list of users, if y'all would be okay with that.
Hope y'all enjoy your new tooling :smile:

Don't know how far we got to doing this but I guess we aren't getting that many issues (nothing compared to bootstrap) so we can revisit this later


Settings Configuration from Main Menu do not Persist

If you are the the main menu and change mod configurations, they do not persist when you actually hit "Resume Expedition", and will only persist if changed under the Pause Menu from in game.

This is fixed


get /explore/{collection}/_search returns source fields while they are in exclude parameter and not in include

In gitlab by @sylvaingaudan on Jul 19, 2017, 17:16
A requests that specifies an exclude on * should not return any source in the hits:
http://localhost:9999/arlas/explore/level0_enriched/_search?pretty=false&human=false&exclude=*&size=10
But it returns all the fields.

In gitlab by @sylvaingaudan on Jul 21, 2017, 12:10
changed milestone to %7

In gitlab by @sfalquier on Jul 21, 2017, 14:07
added ~1918367 label

In gitlab by @sylvaingaudan on Jul 21, 2017, 15:38
changed milestone to %6

In gitlab by @sfalquier on Jul 21, 2017, 17:05
removed ~1918367 label

In gitlab by @sfalquier on Jul 28, 2017, 10:27
added ~2377174 label

In gitlab by @sfalquier on Jul 28, 2017, 11:04
Projections "include" and "exclude" are not implemented for search and geosearch. It's a missing feature.

In gitlab by @sylvaingaudan on Aug 10, 2017, 08:31
changed milestone to %10

In gitlab by @sfalquier on Aug 18, 2017, 16:42
added ~2424199 and removed ~2424198 labels

In gitlab by @sfalquier on Aug 18, 2017, 17:48
mentioned in commit fcfac2232e7f4edcea9bfdb41d8bf2f395efc903

In gitlab by @sfalquier on Aug 18, 2017, 17:53
assigned to @sfalquier

In gitlab by @sfalquier on Aug 21, 2017, 09:37
mentioned in merge request !81

In gitlab by @MohamedHamouGisaia on Aug 25, 2017, 09:09
closed via merge request !81

In gitlab by @MohamedHamouGisaia on Aug 25, 2017, 11:48
mentioned in commit bbae4936fad104f9c097bb5573ce1821e23be65c


path_maps path to a local symlink causes ignoring breakpoints, goes straight to completion

EDIT: I hadn't been able to figure out why breakpoints were being skipped when the vdebug connection otherwise worked properly. It turns out if a path_maps path contains a symlink, it will not work properly.
In my case, /var/www is a symlink to /home/derek/www
So this has the issue where breakpoints fail
let g:vdebug_options['path_maps'] = {'/var/www/local.laravel': '/var/www/local.laravel'}

And this works properly
let g:vdebug_options['path_maps'] = {'/var/www/local.laravel': '/home/derek/www/local.laravel'}

Below is the original issue as posted

Sorry if this is the wrong place for this but I don't know where this is failing. I have a successful connection and can step forward in the code. But setting a breakpoint then pressing F5 to go to the breakpoint (or disabling break on entry) will execute the rest of the code without hitting the breakpoint and I can't figure it out.
I've tried various versions of setting path_map without any success.
I am able to successfully configure xdebug without issue outside of Docker. Just when the image is running, the breakpoints don't stop despite being set. I've gone through old issues describing similar things but they seem to eventually reach the conclusion of it being fixed in a later version.
vdebug.log (I removed the lines for keymapper that severely bloated the output, if they're needed I can add them.
- [Debug] {Mon 16 2019 22:19:47} Started
- [Debug] {Mon 16 2019 22:19:47} Listening on port 9000
- [Debug] {Mon 16 2019 22:19:47} Closing the socket
- [Debug] {Mon 16 2019 22:19:47} Closing the socket
- [Debug] {Mon 16 2019 22:20:49} Creating hidden buffer: [' ● [<F5> Start] [<F6> Stop] [:help Vdebug]']
- [Debug] {Mon 16 2019 22:20:49} Creating hidden buffer: ['[0] {main} @ /var/www/local.laravel/public/index.php:10', '']
- [Debug] {Mon 16 2019 22:20:49} Creating hidden buffer: ['[ *Locals ] [ Superglobals ] [ User defined constants ]', '', '- Locals at /var/www/local.laravel/public/index.php:10', '', ' ⬦ $app = (uninitialized)', ' |', ' ⬦ $kernel = (uninitialized)', ' |', ' ⬦ $request = (uninitialized)', ' |', ' ⬦ $response = (uninitialized)', '']
- [Debug] {Mon 16 2019 22:20:52} Finishing socket server
- [Info] {Mon 16 2019 22:20:52} Vdebug stopped waiting for a connection
- [Debug] {Mon 16 2019 22:20:52} Hidden buffer after insert: [' ■ [<F5> Start] [<F6> Stop] [:help Vdebug]']
- [Debug] {Mon 16 2019 22:20:52} Creating hidden buffer: []
- [Debug] {Mon 16 2019 22:21:09} Started
- [Debug] {Mon 16 2019 22:21:09} Listening on port 9000
- [Debug] {Mon 16 2019 22:21:11} Found client, ('<IP_ADDRESS>', 57634)
- [Debug] {Mon 16 2019 22:21:11} Finishing socket server
- [Debug] {Mon 16 2019 22:21:11} create session
- [Debug] {Mon 16 2019 22:21:11} start session
- [Debug] {Mon 16 2019 22:21:11} Setting buffer for DebuggerWatch: []
- [Debug] {Mon 16 2019 22:21:11} Setting buffer for DebuggerStack: []
- [Debug] {Mon 16 2019 22:21:11} Setting buffer for DebuggerStatus: []
- [Debug] {Mon 16 2019 22:21:11} Storing existing key mapping, 'vnoremap <F2> :norm@q
'
- [Debug] {Mon 16 2019 22:21:11} Storing existing key mapping, 'nnoremap <F2> :call Marvim_search()
'
- [Debug] {Mon 16 2019 22:21:11} Storing existing key mapping, 'vnoremap <F3> y:call Marvim_template_store()
'
- [Debug] {Mon 16 2019 22:21:11} Storing existing key mapping, 'nnoremap <F3> :call Marvim_macro_store()
'
- [Info] {Mon 16 2019 22:21:12} Found connection from ('<IP_ADDRESS>', 57634)
- [Debug] {Mon 16 2019 22:21:12} Command: context_names -i 1
- [Debug] {Mon 16 2019 22:21:12} Response: <?xml version="1.0" encoding="iso-8859-1"?>
<response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="context_names" transaction_id="1"><context name="Locals" id="0"></context><context name="Superglobals" id="1"></context><context name="User defined constants" id="2"></context></response>
- [Debug] {Mon 16 2019 22:21:12} Available context names: {0: 'Locals', 1: 'Superglobals', 2: 'User defined constants'}
- [Info] {Mon 16 2019 22:21:12} Updated line number of breakpoint 11000 to 16
- [Info] {Mon 16 2019 22:21:12} Registering 1 breakpoints with the debugger
- [Debug] {Mon 16 2019 22:21:12} Command: breakpoint_set -i 2 -t line -f "file:///home/derek/www/local.laravel/routes/web.php" -n 16 -s enabled
- [Debug] {Mon 16 2019 22:21:12} Response: <?xml version="1.0" encoding="iso-8859-1"?>
<response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="2" state="enabled" id="160002"></response>
- [Debug] {Mon 16 2019 22:21:12} starting with step_into (break_on_open = 1)
- [Debug] {Mon 16 2019 22:21:12} Command: step_into -i 3
- [Debug] {Mon 16 2019 22:21:12} Response: <?xml version="1.0" encoding="iso-8859-1"?>
<response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="step_into" transaction_id="3" status="break" reason="ok"><xdebug:message filename="file:///var/www/local.laravel/public/index.php" lineno="10"></xdebug:message></response>
- [Debug] {Mon 16 2019 22:21:12} refresh event
- [Debug] {Mon 16 2019 22:21:12} ** RefreshEvent
- [Info] {Mon 16 2019 22:21:12} Getting stack information
- [Debug] {Mon 16 2019 22:21:12} Command: stack_get -i 4
- [Debug] {Mon 16 2019 22:21:12} Response: <?xml version="1.0" encoding="iso-8859-1"?>
<response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="stack_get" transaction_id="4"><stack where="{main}" level="0" type="file" filename="file:///var/www/local.laravel/public/index.php" lineno="10"></stack></response>
- [Debug] {Mon 16 2019 22:21:12} Replacing remote path (/var/www/local.laravel) with local path (/var/www/local.laravel)
- [Debug] {Mon 16 2019 22:21:12} Replacing local path (/var/www/local.laravel) with remote path (/var/www/local.laravel)
- [Debug] {Mon 16 2019 22:21:12} Replacing remote path (/var/www/local.laravel) with local path (/var/www/local.laravel)
- [Info] {Mon 16 2019 22:21:12} Moving to current position in source window
- [Info] {Mon 16 2019 22:21:12} Setting source file: /var/www/local.laravel/public/index.php
- [Debug] {Mon 16 2019 22:21:12} Setting source line number: 10
- [Info] {Mon 16 2019 22:21:12} Placing pointer sign on line 10
- [Debug] {Mon 16 2019 22:21:12} ** GetContextEvent
- [Info] {Mon 16 2019 22:21:12} Getting Locals variables
- [Debug] {Mon 16 2019 22:21:12} Command: context_get -i 5 -c 0 -d 0
- [Debug] {Mon 16 2019 22:21:12} Response: <?xml version="1.0" encoding="iso-8859-1"?>
<response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="context_get" transaction_id="5" context="0"><property name="$app" fullname="$app" type="uninitialized"></property><property name="$kernel" fullname="$kernel" type="uninitialized"></property><property name="$request" fullname="$request" type="uninitialized"></property><property name="$response" fullname="$response" type="uninitialized"></property></response>
- [Info] {Mon 16 2019 22:21:12} Writing 4 properties to the window
- [Debug] {Mon 16 2019 22:21:12} Writing to window:
[ *Locals ] [ Superglobals ] [ User defined constants ]

- Locals at /var/www/local.laravel/public/index.php:10

 ⬦ $app = (uninitialized)
 |
 ⬦ $kernel = (uninitialized)
 |
 ⬦ $request = (uninitialized)
 |
 ⬦ $response = (uninitialized)

- [Debug] {Mon 16 2019 22:21:12} ** TraceRefreshEvent
- [Debug] {Mon 16 2019 22:21:14} ** RunEvent
- [Info] {Mon 16 2019 22:21:14} Running
- [Debug] {Mon 16 2019 22:21:14} Command: run -i 6
- [Debug] {Mon 16 2019 22:21:14} Response: <?xml version="1.0" encoding="iso-8859-1"?>
<response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="run" transaction_id="6" status="stopping" reason="ok"></response>
- [Debug] {Mon 16 2019 22:21:14} ** RefreshEvent
- [Info] {Mon 16 2019 22:21:14} Debugging session has ended
- [Info] {Mon 16 2019 22:21:14} closing connection because status is stopped
- [Info] {Mon 16 2019 22:21:14} Closing the connection
- [Debug] {Mon 16 2019 22:21:14} Closing the socket
- [Debug] {Mon 16 2019 22:21:14} ** ListenEvent
- [Debug] {Mon 16 2019 22:21:14} Started
- [Debug] {Mon 16 2019 22:21:14} Closing the socket
- [Debug] {Mon 16 2019 22:21:14} Listening on port 9000
- [Debug] {Mon 16 2019 22:21:14} Closing the socket

.vimrc vdebug config
let g:vdebug_options = {}
let g:vdebug_options['port']=9000
let g:vdebug_options['path_maps']={'/var/www/local.laravel': '/var/www/local.laravel'}

php.ini xdebug
xdebug.remote_host             = host.docker.internal
xdebug.remote_autostart        = 1
xdebug.remote_enable           = 1
xdebug.remote_port             = 9000
xdebug.default_enable          = 1
xdebug.remote_connect_back     = 1
xdebug.var_display_max_depth = -1
xdebug.var_display_max_children = -1
xdebug.var_display_max_data = -1

Dockerfile
FROM php:7.4-apache

# install linux packages
RUN apt-get update && apt-get install -y \
    git \
    libzip-dev \
    zip \
    curl

# install and enable PHP extensions
RUN pecl install -o -f xdebug-2.8.1
RUN docker-php-ext-install bcmath
RUN docker-php-ext-install calendar
RUN docker-php-ext-configure zip --with-libzip
RUN docker-php-ext-install zip
RUN docker-php-ext-enable xdebug

# clear tmp pear install files
RUN rm -rf /tmp/pear;

# copy virtualhost files into the container
COPY ./sites-available/* /etc/apache2/sites-available/

# copy php.ini
ADD ./php.ini /usr/local/etc/php/

# enable the sites
RUN cd /root \
    && ln -s /etc/apache2/sites-available/local.laravel.conf /etc/apache2/sites-enabled/

docker-compose.yml
version: '3.2'
services:
  web:
    build: .
    ports:
      - "80:80"
      - "443:443"
      - "8080:8080"
    volumes:
      - /var/www:/var/www:cached
    environment:
      - PATH=/root/bin:/root/.composer/vendor/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

When it's started with break on entry

After I hit F5 with a break in the controller

My local and docker PHP version output is the same
PHP 7.4.0 (cli) (built: Nov 28 2019 07:27:06) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.0, Copyright (c), by Zend Technologies
    with Xdebug v2.8.1, Copyright (c) 2002-2019, by Derick Rethans

Thanks in advance for any suggestions or insight.

Thanks, I'll reproduce this locally and figure out a fix


[SPARK-41830][CONNECT][PYTHON][TESTS][FOLLOWUP] Enable parity test test_sample

What changes were proposed in this pull request?
Enable parity test test_sample
Why are the changes needed?
For test coverage
Does this PR introduce any user-facing change?
no, test-only
How was this patch tested?
enabled test

Could you rebase this PR, @zhengruifeng ? There is a conflict after merging your another PR in this area.

@dongjoon-hyun Sure, thanks for the reviews of these test PRs!


Error message

In firefox developer edition i get this when browsing localhost:8000
Warning: React attempted to reuse markup in a container but the checksum was invalid. This generally means that you are using server rendering and the markup generated on the server was not what the client was expecting. React injected new markup to compensate which works but you have lost many of the benefits of server rendering. Instead, figure out why the markup being generated is different on the client or server:
(client) morphic-starterkit" id="a11y-3" data-rea
(server) morphic-starterkit" data-reactid=".k4ckr warning.js:48:7
Server-side React render was discarded. Make sure that your initial render does not contain any client-side code.
I have not made any changes just cloned git...
/K

Chrome console outputs the same warnings and errors.

I was able to fix this by moving the a11y code to the bottom of client.js.
Haven't had enough time to confirm that all the features of a11y still work. I can say that I am getting some a11y console messages, so it is promising.
However, the error doesn't fully go away. For instance I have markup with an apostrophe:
(client) bovugw.0.1">Here you're sure to fin
(server) bovugw.0.1">Here you're sure to find! a

This is actually a red herring. The difference between of server-side and client-side markup is somewhere else. It is actually a pain to find out and this red herring of the wrong difference is also not helping. will follow up with a reference to a similar issue.

I'm going to remove react-a11y because the lack of development interest & some of the open issues are pretty severe. Here's the list: https://github.com/rackt/react-a11y/issues
https://github.com/rackt/react-a11y/issues/77
https://github.com/rackt/react-a11y/issues/78
https://github.com/rackt/react-a11y/issues/79 (React 0.14)


Update social links to include Mastodon

[ ] Official mastodon account: https://hachyderm.io/@anysoftkeyboard.
[ ] Remove all Google Plus references
[ ] Keep twitter? Or remove it?

@AnXh3L0 can you take a look at this?

@AnXh3L0 I think I added Mastodon correctly. Can you check?

Hi @menny, yes, you added it correctly.


[windows] convert all files to snake case or similar

https://github.com/louis030195/screen-pipe/pull/46
audio files still have spaces, which would crash windows I assume
anyone want to help on this easy issue? maybe @wangshifeng :)?

yes, i am happy to fix this issue.

i run this on windows and have no issue with the space actually


Entities vs DTOs

Hi @mmacneil
Great seeing new stuff being added daily.
In fact, I am working on a very similar pet project using TypeScript instead of C#, so your project gives me a really good starting point, cheers.
My questions for you at this point are:

why Token.cs is listed under Dto, but User.cs is under Entities? I would expect both to be under Entities.
what's the best definition for dtos?

Hey @lucianlature - great question and one I bump one into regularly myself as I find it's not always initially apparent when trying to model a new concept in a domain whether it should be an Entity, Value or Dto.
Like everything, there's no definitive answer or checklist one can apply to make that distinguishment but here are a few guidelines you may find useful.
Identity - An Entity has an Id.  Think of classic examples: Customer, Order, Product etc.  - in any system or model the identity of those things matters.  The Id of an Address for a Customer or the Price of a Product usually doesn't so they can be set up as Value objects in the domain.  This also directly relates to their equality because entities contain inherent identity we use their Id to determine equality, i.e., it's possible we could have two customers with Name == "John Doe" but their Id distinguishes them as being different.  For values, we typically use their structure to determine equality, i.e., we have two price objects that look like { Amount = 4.25, TaxPct = 15 } but our object model treats them as the same because structurally they are and can be used interchangeably with no impact.  Another way to think about this is that Value objects cannot live on their own - they typically always belong to one or more entities.
Lifespan - Entities are almost guaranteed to change in the future.  An Order will have products added or removed over time, a Customer accumulates orders over time and so forth.  We rely on their Id to help track these changes to their state over time.  Value objects have no lifespan and can be created or destroyed at any point with no impact because they are interchangeable.
Immutability - This is directly related to the previous rule.  A value should be immutable, and if we find ourselves needing to mutate it over time (thereby giving it a lifespan), then it is likely not a value at all and should probably be converted to an entity within the model.
What's the best definition for dtos?
I think of these as vessels for shuttling data in and out of objects (request/response objects in use cases as in this example), OR across boundaries of the application, i.e. a mobile app client sends a LoginRequestDto to the rest API.  I try to keep them nice and light (no behavior or serialization details) and based on primitive types or composed of dto types following the same rules.  Martin Fowler has an excellent description too


Extending (extruding?) rot.js

Hi! I'm the coding half of the team that made Deiphage for the 2024 7DRL jam, which you can see live on my repo's GH Pages site at https://dmchurch.github.io/7drl-2024/. As you can see, I've added another layer to the standard usage of rot.js - it is a classic roguelike set on a 3D tile grid 😂 I ended up creating specializations of a lot of the rot.js internal classes in order to cope with the 3D aspect of it, obviously!
I've been wanting to continue building on the idea, so I thought that now that I'm out of the frantic rush of the jam, I'd go back over all the dirty hacks I made and turn them into something that I could reuse and extend further, and that means making some fairly substantial edits to the rot.js codebase in order to support a varying number of dimensions on the majority of classes.
My question is, would you be interested in this as a potential direction (no pun intended) for the rot.js project to go in, and if so, should I work on this with the intent that it gets absorbed back into the main rot.js codebase? If so I'll work to maximize compatibility with existing projects using rot.js, and I'll also probably do some modernization of the TS code while I'm in there.
If not, that is entirely fine - it just means that I'll be creating a split for personal use, which will certainly be easier from a coding standpoint! But let me know - it'd be fun to see other rot.js projects using the stuff I've been working on, cause I can think of all sorts of ways you could use an extensible layered tile display in the browser 😄

Hi @dmchurch ,
thanks for the proposal! It is certainly an interesting food for thought.
I would say that while your extension to third dimension is worthwile, I am not sure it makes sense to apply it to existing rot.js objects (such as the ROT.Display class). Instead, perhaps introducing new 3d-based interfaces would be more sensible?
My intuition here is that 2d is still the main usecase for 95% of users, so it makes little sense to provide them with a more complex codebase. (The existing TS code might definitely use some modernization efforts, though.)
Apart from the the Display class, what other components of rot.js would you see fit for providing a three-dimensional API?

I am not sure it makes sense to apply it to existing rot.js objects (such as the ROT.Display class).

Oh I wholeheartedly agree that the ROT.Display class in particular wants to remain a 2D-only class! It's just far too useful to have a lightweight, simple Canvas manipulator - for example, the inventory display in Deiphage (which is coded as a popover <dialog> rather than an in-Canvas menu, since we're using a non-text tile display) uses a single ROT.Display of size 1×1 to display each item, which can then have a CSS outline applied to it when it's selected. That said, I would like to add a custom Web Component that can be used to instantiate a Display, so that you could just do
ROT.Display.registerPreset("light", {
    width: 80,
    height: 24,
    layout: "tile",
    bg: "black",
    tileWidth: 16,
    tileHeight: 16,
    tileSet: Tileset.light.img,
    tileMap: Tileset.light.tileMap,
});

and then
<rot-display preset="light" width="1" height="1" fg="red" bg="transparent">!</rot-display>

to render a single-tile Display containing a red ! tile, and perhaps
<rot-display preset="light">

┌───┐

│.>.│

<EMAIL_ADDRESS>
│..f│

└───┘

</rot-display>

to render a static image of a classic Nethack-style room with a cat, like you might want to show in a help screen; for older browsers that don't support Web Components (few and far between, these days), those tags would gracefully fall back to showing a useful text-based rendering of the desired content.
But no, in terms of 3D-esque rendering like I'm doing, I'd instead probably just import something like my Viewport class, which would act as

a container for multiple layers of Displays (and could contain methods to add or remove the number of layers rendered dynamically),
a cropping frame to display only a subset of the actual rendered Display, so that you could have a scrolling viewport without having to redraw the entire frame every time like I'm doing, as long as you're willing to set your Display to the size of your full world map, and
a portal to duplicate a Display being rendered elsewhere but with different settings or different cropping; think of having an inset minimap that mirrors the active game Display but using tiny tiles

Instead, perhaps introducing new 3d-based interfaces would be more sensible?

Yeah, my original inclination had been to just add a set of classes with a new 3d interface, the way I have Cellular3D, Astar3D, etc in my code. But I realized while I was working on it that there's a way to merge the 2D and 3D implementations and also allow someone to use a 4D or even 5D implementation in case, say, you wanted to track a 3D world through time, or through alternate realities, or whatever. (I could imagine using the same technique I used in Cellular3D to create z-layers that are "somewhat similar" to each other being used to instead generate alternate dimensions that are similar to but not identical to the primary, for example.)
Specifically, my thought is that instead of extending the existing rot.js code from two dimensions (with all the nested for loops to iterate through x and y) I instead reduce the code to 1 dimension. All internal coordinate-based data storage, like the internal _map of the map generator classes or the _todo/_done of the pathfinders, now just operate on a single numeric index coordinate, but they translate it back to a paired x/y coordinate to call the callbacks. They can then modify their this._dirs property to convert the x/y coordinates from DIRS into index deltas based on the total size of the map in question. Changing the internal code to use 1-dimension coordinates brings a number of advantages, like being able to use the native TypedArray classes for fast and compact map storage 😄
As for communication to/from calling code, I'd change the places that currently expect or provide separate x and y parameters to instead use a single coord parameter. On output (i.e. when calling a user-supplied callback) these would be objects of the form {x: number, y: number}, meaning that existing code could change from function(x, y, what) to function({x, y}, what) without any other changes. As for input, I'd provide some new top-level helper functions in the ROT namespace called XY and XYZ, which take numeric arguments and return coordinate objects, so existing code could take compute(x, y, callback) and change it to compute(XY(x, y), callback). Of course I'd provide a separate wrapper API that mimics the existing 2D call signatures, since that becomes pretty simple!

My intuition here is that 2d is still the main usecase for 95% of users, so it makes little sense to provide them with a more complex codebase.

I wholeheartedly agree with you here - that 95% is likely an underestimate, even! but there are really interesting things you can do with the ability to temporarily or partially extend your game to 3D. For example, in a classic Nethack-style game, you could add a second layer above the gameplay layer which only renders room walls, to give them a feeling of depth without changing the gameplay. Or you could have a dungeon floor with a hole in it and render a temporary layer below, through which you could have the player able to see what they'd be dropping onto if they step onto it. Or, for a more open-environment game than a dungeon crawler, you could use extra z-layers to, say, render trees or buildings at realistic-looking heights, which is what Door in the Woods does, and where my teammate got the idea for the parallax rendering that I used for Deiphage. I highly recommend checking out the Steam page for that game for video of what you can do with this kind of rendering when done outside the rushed context of a game jam - I'd love for that kind of look to be available to folks that don't have my level of comfort mucking around with foreign code and display algorithms!
All that said, of course, it would be an API-breaking change. Even if I made the wrapper functions the default exposed API and required consumers to choose the advanced API explicitly, the internal computation contexts require an understanding of the world-coordinate bounds in order to translate between index and (x, y) coordinate. You could make it compatible with probably 90% of existing code by assuming that the width and height passed to the first Display class constructor represent the total applicable world-bounds, but that will fail whenever someone is doing the kind of moving-viewport display that I'm doing. So, there's no question but that it'd require a major-version bump with a bit of warning documentation saying "you can PROBABLY migrate your code just by changing your import to this, but make sure to check to make sure nothing breaks".

Also worth noting, I might take some of the more genericizable classes I made for Deiphage and import them into rot.js for external use. The input layer I designed, in particular - I coded it with an eye to making it extensible, and it would give rot.js users the ability to do input handling that could natively handle keyboard/mouse/touch entry, which would be super useful if you're in a jam (pun definitely intended). And, while I very much appreciate the way that rot.js hands you tools and then gets out of the way, I could definitely see an argument for importing something like my WorldMap, which would be a batteries-included way to link generation, storage, and display that you could extend, to let you get up-and-running more quickly. And finally I could take the currently-not-recommended ROT.Engine namespace and use it to host a set of classes you could build on that would implement the Actor pattern suggested there. Just some thoughts 😄

Yeah, these are solid ideas, definitely a lot to chew on.
I think it would now be useful to divide the whole set of ideas into three disctinct areas:

declarative UI
more dimensions
misc

And try to focus on these independently. Let me share my opinions about that:
1. Declarative UI
I am a big fan of Custom Elements, so <rot-display> looks pretty interesting to me. Actually, after I finished my current 7DRL (https://github.com/ondras/roguezombies), I caught the idea of a new CustomElement-based DOM renderer for tile-based maps.
I would say that the implementation of the said <rot-display> can be done separately from the underlying ROT.Display JS instance.
Presets are yet another story. Once the <rot-display> is done, it can provide an interface for preset definition (via static methods) to be re-used by the preset attribute. Once again, there is no need for the user to interface with the low-level ROT.Display.
2. More dimensions
The idea looks simple on paper, but I am afraid you might run into issues in some algorithms that are strongly bound to the 2d realm. I would suggest trying that in a separate branch/fork and see how it goes.
Also, I like the idea of a coord single parameter, but I would argue that perhaps a number[] might be more useful when compared to {x:..., y:...}.
3. Misc
There is this weird namespacing-legacy thingy when ROT components are often available in the ROT.* namespace, but this works only if you use the pre-built JS version. Once you go for the typescript code, you import modules as necessary, naming them locally in the process. I would say that the second approach is currently the right way to go: providing individual components via ES modules, so that there is no need to usurp the ROT.Engine namespace for a particular functionality. The same obviously applies for XY/XYZ classes/objects, that would reside in a dedicated module which contains vector arithmetics etc.
Alternatively, we might want to re-use the great glMatrix project (https://glmatrix.net/) as this is a very reasonable approach for working with multi-dimensional vector data in a memory-efficient way.

1. Declarative UI

I would say that the implementation of the said <rot-display> can be done separately from the underlying ROT.Display JS instance.

Oh definitely. There's absolutely no reason to require that you use a Web Component to render a ROT.Display - declarative should always be just one way to describe a thing.

Presets are yet another story. Once the <rot-display> is done, it can provide an interface for preset definition (via static methods) to be re-used by the preset attribute. Once again, there is no need for the user to interface with the low-level ROT.Display.

You don't think so? I'd been thinking that preset could be added to the DisplayOptions interface as a simple Partial<DisplayOptions> member. I ended up instantiating a lot of Display objects for Deiphage and they all have to use new Display({...Tileset.light.getDisplayOptions(), width: x, height: y}) - I thought it could be nice to just Display.register("light", Tileset.light.getDisplayOptions()) and then be able to use it in my instantiations. That's definitely an "up to you" choice, though, so if you'd rather that only get used for the Web Component that works too!
[On rereading, I think you might have instead been more concerned with the user having to directly import and interact with the ROT.Display class when using the declarative model, and you're absolutely right they shouldn't need to! Even if preset functionality gets implemented in the low-level Display, it seems entirely reasonable to mirror the registerPreset() static method on the ROTDisplayElement class.]
2. More dimensions

The idea looks simple on paper, but I am afraid you might run into issues in some algorithms that are strongly bound to the 2d realm. I would suggest trying that in a separate branch/fork and see how it goes.

Oh yeah for sure, they wouldn't all work out nicely - anything that works with the geometry of it, like the shadowcasters, will only be happy with the dimensionality they're designed for. (I did an extremely abortive attempt to alter the PreciseShadowcasting algorithm to cope with a sphere instead of a circle before deciding that I didn't have time for that, it's a game jam, so I'm just doing the 2d shadowcast on-layer, then dropping a vertical from each visible point to wherever is visible in layers above/below.
That said, anything that only interacts with maps on a neighbor/axis basis - like pathfinding, like generation - will work just fine in whatever dimensionality, though some care needs to be taken regarding bounds; performing "x+1" on the index of a cell at the right edge of a map will result in a valid map index on the left edge of a map. For something like Cellular this can be worked around by expanding the internal map by 1 along all dimensions and forcing a boundary condition on the cells there between each generation, but otherwise it requires doing individual axis-bounds checks of the form (oldX % yStride) === (newX % yStride) (or, for bit-aligned implementations, (oldX & ~xMask) === (newX & ~xMask) - I did that for my WorldMap implementation).
I'll note also that I consider the common topology parameter to be something that would be in addition to any z-topology specification; I'd expect that any dimension after the second can be in any of the three states "no travel along this axis" (the default), "travel along this axis independently from x/y" (the 3d equivalent of "orthogonal only"), or "travel along this axis at the same time as x/y" (the 3d equivalent of diagonal movement). So, Deiphage's movement isn't "topology=10", it's "topology=8, zTopology=independent".

Also, I like the idea of a coord single parameter, but I would argue that perhaps a number[] might be more useful when compared to {x:..., y:...}.

🤦 Right, of course it would - if we're doing multidimensionality by genericizing, then limiting things to "how many coordinate letters can you come up with" is kinda silly, huh! I do like the readability that having the coordinate names gets you for the common case, though, so I think that I'd be likely to make the output side (when passing a value to a callback) a subclass of Array which has a get/set pair (or, perhaps, just a getter) for x, y, z, and w.
The one thing I do want to be cautious about is to avoid too much in the way of allocations - I'd probably specify that "the object that gets passed to the callback function will be reused, don't store the object itself, store its coordinates", and encourage that by making the type "readonly" at the Typescript level. I've had to do a lot of low-level JS optimization for my other major project, Idle Loops, and the number-one performance hit I've found for most algorithms (beyond the obvious "try to keep your big-O notation to a low factor") is avoiding allocations in critical-path functions, which means that a lot of language features like for...of become inaccessible.
3. Misc

There is this weird namespacing-legacy thingy when ROT components are often available in the ROT.* namespace, but this works only if you use the pre-built JS version. Once you go for the typescript code, you import modules as necessary, naming them locally in the process. I would say that the second approach is currently the right way to go: providing individual components via ES modules, so that there is no need to usurp the ROT.Engine namespace for a particular functionality. The same obviously applies for XY/XYZ classes/objects, that would reside in a dedicated module which contains vector arithmetics etc.

Fair enough! I was mainly thinking "namespace" in the sense of "concept space", anyway, like "where does this go in the help docs". The actual code organization matters less. (well. it matters a lot that the code BE organized. it does not matter so much HOW it is organized.)

Alternatively, we might want to re-use the great glMatrix project (https://glmatrix.net/) as this is a very reasonable approach for working with multi-dimensional vector data in a memory-efficient way.

Ooh, I haven't heard of this! I'll have to check it out but yeah, I imagine that could be quite helpful!
Shall I assume, then, that you are at least tentatively interested in bringing this functionality to rot.js? If so I'm delighted to follow your lead on how/where/what to do 😄

On rereading, I think you might have instead been more concerned with the user having to directly import and interact with the ROT.Display class when using the declarative model, and you're absolutely right they shouldn't need to!

Exactly, that was my point 👍

Shall I assume, then, that you are at least tentatively interested in bringing this functionality to rot.js? If so I'm delighted to follow your lead on how/where/what to do 😄

Well, yeah. Please excuse my late response; I am rather busy these days and while I am still interested in both rot.js and roguelike development, I am focusing more on other projects of mine.
As for the work organization: I would suggest making a rot.js fork where you can

introduce the new declarative display overlay / facade,
try experimenting with a multi-dimensional approach.

As for the 2), perhaps pick just one of the existing classes (pathfined, dungeon generator) and try to adjust it accordingly. Let's see how that works -- and what modifications need to be done to the public API.

Sounds good! Once my dev energy isn't wholly focused towards the continuation of our 7DRL project I'll start working on transferring some of my work over using actual proper coding technique rather than rushed jam work 😂

Ah, quick question for you. I'm working on getting a local rot.js development environment set up and testing to make sure the build gets the same results as the existing library, and I'm running into some discrepancies that I'd like to get your take on. Though first, just to check: are you capable of running a full build on your machine and getting the same results as currently checked into the repo? I've been working under that assumption but it occurred to me that it might not be accurate.

[Edited to add: I just now discovered that my fork was not up-to-date with the rebuild you in fact just did! That would have cleared up so many of my issues. Whoops!]

Yep, this was probably the source of confusion.
A full rebuild is currently a little bit problematic with respect to the auto-generated documentation, because the output html changes a bit on each run (includes timestamps). This means that an unrelated JS commit/fix influences a rather large number of files.
One approach would be to not store the documentation in the repository, running the generation task only when publishing via GitHub pages/actions. Unfortunately, I have very little experience in this field and also no time for that.

One approach would be to not store the documentation in the repository, running the generation task only when publishing via GitHub pages/actions. Unfortunately, I have very little experience in this field and also no time for that.

Heh, hear that. I can look into that on my fork as well - I actually recently had to write a custom GH action for my project to publish a manifest with checksums of all the files in the repo, just so that there would be some file on the site that would be guaranteed to change with each update, for cache-checking reasons.
One approach I've seen is to store the documentation in the same repo but on an unrelated gh-pages branch, but it'd be just as easy to run the typedoc task and publish the results to the GH page without storing them in the repo itself. Do you have a preference, between storing the generated docs in an off-branch vs keeping the live docs out of the repository entirely?

Do you have a preference, between storing the generated docs in an off-branch vs keeping the live docs out of the repository entirely?

No. I see both the value of using an Action (the docs being generated stuff that does not belong to the repository, in a puristic view) as well as the value of checking out a project and having the documentation at hand automatically. 🤷

On the latter note I'm already planning to look into generating an offline version of the docs for the main repo itself - strip out all the links and search metadata and it looks like they can generate in a reproducible manner, and I'd be surprised if there wasn't a way to convince typedoc to suppress those. That way the in-source docs don't change on every commit, but the online docs have live links and search functionality.

On the latter note I'm already planning to look into generating an offline version of the docs for the main repo itself - strip out all the links and search metadata and it looks like they can generate in a reproducible manner, and I'd be surprised if there wasn't a way to convince typedoc to suppress those. That way the in-source docs don't change on every commit, but the online docs have live links and search functionality.

Sounds like an optimal combination.

I've started some initial work on the fork! Please feel free to watch development on the rot3d branch when and as you have the time and inclination; I've added the fork as a git submodule in my post-7DRL project and I'm using Typescript's new multi-project build functionality to allow depending on (and rebuilding) the original TS sources of the rot.js code, rather than referencing the prebuilt JS modules as an NPM dependency.
Over the next week or two I'll migrate my monkey-patches and ad-hoc extensions from my 7drl repo into my rot.js fork, so that I can work with them in context and figure out where the pain points are. I'll try and keep the commit history clean on the rot.js side of things, to make reviewing the code easier; I'll let you know when I've got something substantive for you to look at.
I'll probably also be doing some general cleanup and performance improvements in the rot.js library, since performance optimization is one of my areas of expertise, and code cleanup and consistency refactoring are guilty pleasures of mine. I'd recommend that, presuming we can agree on scope and get some or all of my fork merged back into upstream, we make this a major-version change and not just a minor bump. Not because I think any of the existing API needs breaking, but just because I'd expect enough will be changing internally that any code that (like my 7drl code) does monkey-patching or uses advanced TS type manipulation on rot.js types might break in unexpected ways. I'd be much more comfortable declaring "this is a breaking change that might not actually break your code at all" than declaring "this is a non-breaking change unless you did A, B, or C in your code".
Oh and, you should feel free to mimic my setup for Deiphage if you want to try out using my fork as a submodule the way I am. I've set the rot3d branch as the main branch for my fork so that submodules using the bare git URL will fetch the branch I'm working on even without including a -b option.

I've opened #217 for you to take a look at! I'm not expecting it to actually get pulled in at the moment, so there's no rush - I'm leaving it in draft form for the time being, until I have some more substantive and useful changes to show. This should give you an idea of the type of code I write, though, as well as the degree of refactor/change I'm comfortable with.

we make this a major-version change and not just a minor bump

Yeah, no problems here. I am completely okay with larger changes, breaking changes, major versions etc.


Unity Wrapper - Crashes when set to Unity Thread

Issue Overview
I have successfully installed the Unity wrapper and it works properly when the RealSenseDevice's "Process Mode" is set to Multithread. However, the example scene (and any of my test scenes) crash when trying to have the "Process Mode" set to Unity Thread.

Issue Description
When set to Unity Thread the scene will either crash while loading or (more common) will start and collect a few frames and then crash. When this happens, I get an error in the Console:
"Exception: Object does not support "librealsense::depth_sensor" interface!"
Furthermore, the Colorized Depth image is not correct, see the image below:

I have attached my most recent error.log (generated from Unity, which appears to be mostly a memory dump).
As I've mentioned, the wrapper works correctly when the "Process Mode" is set to Multithread.
Any assistance/advice is greatly appreciated - thank you!

System Info

Required Info

Camera Model
D415

Firmware Version
<IP_ADDRESS>

Operating System & Version
Win 10

Platform
Unity -  5.5.1f1

SDK Version
V2.10.0

Thank you for the information, looks like it's coming from the Colorized Depth (or Alignment), as a temporary work around you can disable these objects. Raw streams look ok with unitythread mode

Good suggestion @zivsha and I'll keep you updated if I'm able to solve the issue/find any more information that could help in debugging.
Unfortunately, my project requires the Colorized Depth, so I will rework my code to work in the Multithread mode for the time being.

Confirmed this is also happening for me, crashes on Unity Thread mode every time unless I disable the Colorized Depth and Alignment objects. Multithread works fine.
I would note that I'm also getting the "Exception: Object does not support "librealsense::depth_sensor" interface!" error even in Multithread mode though, but it doesn't appear to break anything?

@c-sja thanks for the information, I've noticed that exception as well and my PR will fix that as well.

Hi guys, please update if the merged change works for you

Hi @zivsha thanks for the changes.
I switched to development branch for your changes. In Unity it's complaining "Assets/RealSenseSDK2.0/Scripts/PointCloudGenerator.cs(19,13): error CS0246: The type or namespace name `PointCloud' could not be found. Are you missing an assembly reference?"
Did I need to update the SDK as well or something? I have version 2.10.0 from 11 days ago, which appears to be the most recent.

@c-sja
Perhaps development branch PointCloud add has not yet been reflected in LibrealsenseWrapper.dll.
Copy  csharp wrapper source code from development branch to unity your project.
https://github.com/IntelRealSense/librealsense/tree/development/wrappers/csharp/Intel.RealSense

@unagiHuman That worked thanks!


Stop publishing RCs

They consistently cause build issues for us (we haven't even tried 6.0 RCs for a while because of this), so rather than continuing to fight the tape, let's just drop these instead.

With https://jira.mongodb.org/browse/SERVER-77383 fixed ❤ we can instead do https://github.com/docker-library/mongo/pull/622 to have buildable RC's for any release instead of removing them.


Split traits into read, mutate and build

This is a pure API change and should have no performance impact. The goal here is to split out different aspects for the value trait to allow implementing only parts of it. Since 0.2 is a declared breaking API it feels like the right time to do.
This will allow us to do things like make non mutable Value variants that have better performance or even serialise directly to objects.

This is I think what's needed for the new Value Trait's - ready for review / merge


Parameter 0 of constructor in com.example.uploadingfiles.FileUploadController required a bean of type 'com.example.uploadingfiles.storage.StorageService' that could not be found.

I get the above error when I'm trying to build the project.

I get the same message with the demo project.  Parameter 0 of constructor in com.example.springdemouploadingfiles.FileUploadController required a bean of type 'com.example.springdemouploadingfiles.storage.StorageService' that could not be found.

@pramodya1994  @ahowe442  I was also getting this when I was following the spring guide. I added FileSystemStorageService as in gs-uploading-files/complete and it got resolved.

@sandeepan-nath thank you!  I wish that fixed it for me, but it did not.  Are you using maven? or Gradle?  I'm using gradle.

@ahowe442  I must have used maven.

I got that error too. This is how I solved it: Place the @Autowired annotation on top of the StorageService field.

You need to add the @Component on top of the StorageSerivce class so the SpringBoot can detect it.

You need to add the @component on top of the StorageSerivce class so the SpringBoot can detect it.

this doesn't work for me

I get the same message with the demo project. Parameter 0 of constructor in com.example.springdemouploadingfiles.FileUploadController required a bean of type 'com.example.springdemouploadingfiles.storage.StorageService' that could not be found.

add the FileSystemStorageService.java file (complete/src/main/java/com/example/uploadingfiles/storage/FileSystemStorageService.java) in the same package and build it.

I assigned this to myself, because it looks like we missed telling people to add FileSystemStorageService in the readme.

It turns out that adding it is covered in the readme file, so I can close this one.


JupyterHub doesn't see JupyterLab

Issue description
When JupyterLab has been installed with JupyterHub, the hub should have an URL of the form http://localhost:8000/user/jluttine/lab to launch JupyterLab (see https://jupyterlab.readthedocs.io/en/stable/user/jupyterhub.html). However, this doesn't seem to work for some reason although I added jupyterlab to propagatedBuildInputs of jupyterhub.
Steps to reproduce
Add jupyterlab to propagatedBuildInputs of jupyterhub. (And also notebook if you don't have it there already, see #58542.)
Launch nix shell with nix-shell -p python3Packages.jupyterhub.
Launch Jupyter Hub with jupyterhub.
Open localhost:8000in your browser and log in (with your actual Linux username and password).
Try to open URL: http://localhost:8000/user/jluttine/lab (replace jluttine with your username).
Instead of opening JupyterLab, you'll see 404 error page.
Technical details
$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 4.14.103, NixOS, 19.09.git.1233c8d (Loris)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.2`
 - nixpkgs: `/etc/nixpkgs`

Turns out that the docs were a bit incorrect. The Hub needs to be launched as:
jupyterhub --Spawner.cmd='jupyter-labhub'

Then it works.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/anyone-has-a-working-jupyterhub-jupyter-lab-setup/7659/1


Link to windows tarball is no longer valid

I wanted to get dep for windows, but the link:
https://go.equinox.io/github.com/golang/dep/cmd/dep
Does not work anymore, gives 404.

Any updates on this? Still having the issue

I'm still seeing this issue. Did anyone find what the correct link is?

no one?

Dep was officially deprecated earlier this year, and the proposal to archive this repository was accepted. As such, I'm closing outstanding issues before archiving the repository. For any further comments, please use the proposal thread on the Go issue tracker. Thanks!


New installation instructions

Are there any changes in the installation process after this big architectural change introduced in #1597? I wasn't able to install flynn to my cluster following current documentation.

@Vaultman Looks like the discovery token is missing from the bootstrap command, is that where you encountered the problem?

Well, I run flynn-host init --init-discovery on one node, flynn-host init --discovery https://discovery.flynn.io/clusters/{$token} on others, successfully started flynn on all nodes with start flynn-host and then CLUSTER_DOMAIN=mydomain.com flynn-host bootstrap --min-hosts=3 on the first note. As I remember, it failed on waiting for other hosts.

Try specifying --discovery TOKEN to the bootstrap command. I just opened #1611 which should fix this.

Thank you, will try when I have some time.

yep, it was the missing discovery token. Works like a charm now. Thanks.


python wheel: Fail to run twine upload vtk-9.0.20200612-cp38-cp38-linux_x86_64.whl

Hi,
I registered my account on pypi and want to upload the vtk python wheel created by me to pypi, but meet the following error:
$ twine upload vtk-9.0.20200612-cp38-cp38-linux_x86_64.whl
Uploading distributions to https://upload.pypi.org/legacy/
Uploading vtk-9.0.20200612-cp38-cp38-linux_x86_64.whl
100%|████████████████████████████████████████| 541M/541M [02:27<00:00, 3.85MB/s]
NOTE: Try --verbose to see response content.
HTTPError: 403 Client Error: The user 'hongyi-zhao' isn't allowed to upload to project 'vtk'. See https://pypi.org/help/#project-name for more information. for url: https://upload.pypi.org/legacy/

Any hints for this problem?
Regards.

You cannot upload a wheel on pypi that you do not own or maintain, that would allow anyone to hijack the PyPI wheels.  Only maintainers/owners can do so.  So please do not try to upload wheels for packages you do not maintain or own on pypi.

Thanks for your notes. I find the private-pypi which let me create my own pypi repo with flexiable backend, say, github.


1.0.4 - Analyse PHP symbols without loading their files

This pull request fixes #21
Issue #21 describes how the files that are analyzed are loaded in the active code base. When DependencyGuard is used to analyze files that are also present in the active code base, they can conflict and cause fatal errors.
This pull requests implements BetterReflection to determine all necessary information about code symbols without loading in their files, through the autoloader.
N.B.: This pull request should not be merged before @Idrinth confirms this solves the issue.

It seems the patch in it's current state is insufficient. Please allow a few days for this to be picked up again.


missing quotation marks in README.md

Added quotation marks in an example.

The code is correct. The parameter solver requires a function not a string. The function should take as input a CSP instance (a pair of structures) and outputs an iterator over solutions.


FreeBSD port/package created!

https://cgit.freebsd.org/ports/commit/?id=01d001339cfac6cfd842cf2cebc057f3db0e3330

I appreciate the vote of confidence!
I've noticed this:
+post-extract:
+	${REINPLACE_CMD} 's|python3|${PYTHON_VERSION}|g' ${WRKSRC}/cargo-crates/varnish-*/src/lib.rs

Is there something I could do to save you that operation?

Perhaps some way to specify the python binary; maybe via environment variable or the like?
FreeBSD doesn't install a python or python3 symlink anymore.  It's just pythonX.Y for the specific version that is installed--which could be multiple different ones at the moment.

got it, I'll track this here, and will update this ticket once it makes it's way here

hi there, I just pushed v0.0.2 which should close this (just export the PYTHON variable). Please yell if it doesn't!


Links in the README.md are broken/not updated

For example issue link below this header
https://github.com/vknabel/vscode-swift-development-environment/blob/master/README.md#other-questions

Thanks a lot @avinal! Could you find another broken link?

Yeah I had a few yesterday, I forgot them 😅, I will see again and let you know.👍

I think there are no more, I checked, it might be some problem in VS Code.


Support creating new DM channels.

Usage:
				if not message.author.channel then
					client:openDirectMessage(message.author.id)
				end
				if message.author.channel then
					message.author.channel:sendMessage(content)
				else
					message:reply('For some reason I cannot direct message you! Please send me a direct message to open the channel for me :kissing_heart:')
				end

Firstly, thanks for the PR :yum: ! Are you on the latest lit-published version? I am pretty sure I fixed the roles issue already. About creating private channels, I guess having a sendMessage method under User would make more sense as you would be able to just pass sendMessage arguments as if it was Channel's method and it would create the channel itself if not present. And as a side-note, using local for dmChannel would be better too.

Haha yeah the missing local on dmChannel is a bug :)
I figured there would be a nicer way to integrate this into your API -- my example usage of forcing the user to perform a null check is kinda abrasive.
Having message.author:sendMessage automatically open a new DM channel when required would be much cleaner.
As for the other issue with roles, I was working off a github version -- I'm pretty sure it's the version  that's forked in hodgman:master at the moment.

I am pretty sure the double check is required because there may be a delay from when the DM object is dispatched to the CHANNEL_CREATE event to when you are trying to send a message through that channel - so that you are trying to send a message before the DM's Channel structure is Cached. That's most likely an issue with Lua, I am not sure myself about that though. That being said, I will be adding a sendMessage method to the User structure that handles DM creation if not present.
About roles, I am running latest pushed code and both methods work fine. I am not getting any role removed except the one expected. Now, you may try pulling latest files from the master branch and try again, once that is solved I guess we may then proceed and successfully close this PR!

Thanks :+1: