text:
[BUG] failed to run cargo run --release --example loop

Bug Report
failed to run cargo run --release --example loop
Steps to Reproduce

install rustup

install risczero
cargo install cargo-binstall
cargo binstall cargo-risczero
cargo risczero install

ensure risc0 toolchain is installed

(base) mint@Z400:~/risc0$ rustup toolchain list --verbose | grep risc0
risc0 (default) /home/mint/.local/share/cargo-risczero/toolchains/x86_64-unknown-linux-gnu_test-release-2/rust

download risc0 code and run  cargo run --release --example loop

git clone https://github.com/risc0/risc0
cd risc0
cargo run --release --example loop

Expected behavior
The command can run successfully
Your Environment

risc0-zkvm version: v0.19.0 (I also tried v0.19.1 and main, the same issue)
Rust version:  rustc 1.74.1 (a28077b28 2023-12-04)
Platform/OS: ubuntu 22.04

Additional context
build log:
(base) mint@Z400:~/risc0$ cargo run --release --example loop
   Compiling proc-macro2 v1.0.70
   Compiling unicode-ident v1.0.12
   Compiling cfg-if v1.0.0
   Compiling libc v0.2.150
   Compiling quote v1.0.33
   Compiling syn v2.0.39
   Compiling autocfg v1.1.0
   Compiling jobserver v0.1.27
   Compiling cc v1.0.83
   Compiling version_check v0.9.4
   Compiling bitflags v2.4.1
   Compiling serde v1.0.193
   Compiling memchr v2.6.4
   Compiling typenum v1.17.0
   Compiling pin-project-lite v0.2.13
   Compiling const-oid v0.9.5
   Compiling pkg-config v0.3.27
   Compiling generic-array v0.14.7
   Compiling rustix v0.38.27
   Compiling linux-raw-sys v0.4.12
   Compiling hashbrown v0.14.3
   Compiling crypto-common v0.1.6
   Compiling block-buffer v0.10.4
   Compiling subtle v2.5.0
   Compiling digest v0.10.7
   Compiling equivalent v1.0.1
   Compiling itoa v1.0.9
   Compiling futures-core v0.3.29
   Compiling once_cell v1.19.0
   Compiling vcpkg v0.2.15
   Compiling cpufeatures v0.2.11
   Compiling fastrand v2.0.1
   Compiling tempfile v3.8.1
   Compiling sha2 v0.10.8
   Compiling futures-sink v0.3.29
   Compiling serde_derive v1.0.193
   Compiling tracing-attributes v0.1.27
   Compiling slab v0.4.9
   Compiling futures-task v0.3.29
   Compiling futures-channel v0.3.29
   Compiling hex v0.4.3
   Compiling value-bag v1.4.2
   Compiling log v0.4.20
   Compiling futures-macro v0.3.29
   Compiling pin-utils v0.1.0
   Compiling option-ext v0.2.0
   Compiling dirs-sys v0.4.1
   Compiling zeroize_derive v1.4.2
   Compiling getrandom v0.2.11
   Compiling either v1.9.0
   Compiling bytes v1.5.0
   Compiling rand_core v0.6.4
   Compiling directories v5.0.1
   Compiling aho-corasick v1.1.2
   Compiling zeroize v1.7.0
   Compiling regex-syntax v0.8.2
   Compiling fnv v1.0.7
   Compiling ppv-lite86 v0.2.17
   Compiling risc0-build-kernel v0.19.0 (/home/mint/risc0/risc0/build_kernel)
   Compiling num-traits v0.2.17
   Compiling ryu v1.0.15
   Compiling foreign-types-shared v0.1.1
   Compiling foreign-types v0.3.2
   Compiling tracing-core v0.1.32
   Compiling openssl-macros v0.1.1
   Compiling native-tls v0.2.11
   Compiling tracing v0.1.40
   Compiling bytemuck_derive v1.5.0
   Compiling tinyvec_macros v0.1.1
   Compiling scopeguard v1.2.0
   Compiling smallvec v1.11.2
   Compiling anyhow v1.0.75
   Compiling tinyvec v1.6.0
   Compiling indexmap v2.1.0
   Compiling openssl-sys v0.9.97
   Compiling openssl-probe v0.1.5
   Compiling httparse v1.8.0
   Compiling memoffset v0.9.0
   Compiling crossbeam-utils v0.8.16
   Compiling futures-util v0.3.29
   Compiling paste v1.0.14
   Compiling thiserror v1.0.50
   Compiling try-lock v0.2.5
   Compiling crc32fast v1.3.2
   Compiling want v0.3.1
   Compiling rand_chacha v0.3.1
   Compiling bytemuck v1.14.0
   Compiling thiserror-impl v1.0.50
   Compiling num_cpus v1.16.0
   Compiling openssl-src v300.2.0+3.2.0
   Compiling crossbeam-epoch v0.9.15
   Compiling mio v0.8.10
   Compiling socket2 v0.5.5
   Compiling percent-encoding v2.3.1
   Compiling tower-service v0.3.2
   Compiling thiserror-core v1.0.50
   Compiling unicode-bidi v0.3.14
   Compiling futures-io v0.3.29
   Compiling httpdate v1.0.3
   Compiling byteorder v1.5.0
   Compiling form_urlencoded v1.2.1
   Compiling tokio v1.34.0
   Compiling rand v0.8.5
   Compiling thiserror-core-impl v1.0.50
   Compiling num-integer v0.1.45
   Compiling static_assertions v1.1.0
   Compiling adler v1.0.2
   Compiling openssl v0.10.61
   Compiling syn v1.0.109
   Compiling glob v0.3.1
   Compiling miniz_oxide v0.7.1
   Compiling twox-hash v1.6.3
   Compiling http v0.2.11
   Compiling regex-automata v0.4.3
   Compiling num-bigint v0.3.3
   Compiling lazy_static v1.4.0
   Compiling rayon-core v1.12.0
   Compiling cpp_demangle v0.4.3
   Compiling regex v1.10.2
   Compiling ruzstd v0.4.0
   Compiling crossbeam-deque v0.8.3
   Compiling flate2 v1.0.28
   Compiling tokio-util v0.7.10
   Compiling tokio-macros v2.2.0
   Compiling signal-hook-registry v1.4.1
   Compiling stable_deref_trait v1.2.0
   Compiling mime v0.3.17
   Compiling fallible-iterator v0.3.0
   Compiling radium v0.7.0
   Compiling gimli v0.28.1
   Compiling h2 v0.3.22
   Compiling object v0.32.1
   Compiling http-body v0.4.5
   Compiling serde_urlencoded v0.7.1
   Compiling unicode-normalization v0.1.22
   Compiling risc0-sys v0.19.0 (/home/mint/risc0/risc0/sys)
   Compiling itertools v0.11.0
   Compiling zstd-sys v2.0.9+zstd.1.5.5
   Compiling memmap2 v0.5.10
   Compiling unicase v2.7.0
   Compiling backtrace v0.3.69
   Compiling matrixmultiply v0.3.8
   Compiling socket2 v0.4.10
   Compiling encoding_rs v0.8.33
   Compiling ipnet v2.9.0
   Compiling base64 v0.21.5
   Compiling rustc-demangle v0.1.23
   Compiling tap v1.0.1
   Compiling wyz v0.5.1
   Compiling addr2line v0.21.0
   Compiling hyper v0.14.27
   Compiling prost-derive v0.12.3
   Compiling idna v0.5.0
   Compiling rayon v1.8.0
   Compiling addchain v0.2.0
   Compiling tokio-native-tls v0.3.1
   Compiling risc0-core v0.19.0 (/home/mint/risc0/risc0/core)
   Compiling heck v0.4.1
   Compiling rawpointer v0.2.1
   Compiling semver v1.0.20
   Compiling funty v2.0.0
   Compiling serde_json v1.0.108
   Compiling bitvec v1.0.1
   Compiling hyper-tls v0.5.0
   Compiling ff_derive v0.13.0
   Compiling url v2.5.0
   Compiling futures-executor v0.3.29
   Compiling num-complex v0.4.4
   Compiling autotools v0.2.6
   Compiling risc0-zkp v0.19.0 (/home/mint/risc0/risc0/zkp)
   Compiling camino v1.1.6
   Compiling prettyplease v0.2.15
   Compiling zstd-safe v5.0.2+zstd.1.5.2
   Compiling protobuf-src v1.1.0+21.5
   Compiling ndarray v0.15.6
   Compiling futures v0.3.29
   Compiling mime_guess v2.0.4
   Compiling reqwest v0.11.22
   Compiling ff v0.13.0
   Compiling prost v0.12.3
   Compiling risc0-circuit-recursion-sys v0.19.0 (/home/mint/risc0/risc0/circuit/recursion-sys)
   Compiling risc0-circuit-rv32im-sys v0.19.0 (/home/mint/risc0/risc0/circuit/rv32im-sys)
   Compiling blake2 v0.10.6
   Compiling home v0.5.5
   Compiling risc0-zkvm-platform v0.19.0 (/home/mint/risc0/risc0/zkvm/platform)
   Compiling termcolor v1.4.0
   Compiling fixedbitset v0.4.2
   Compiling humantime v2.1.0
   Compiling petgraph v0.6.4
   Compiling which v4.4.2
   Compiling prost-types v0.12.3
   Compiling downloader v0.2.7
   Compiling cargo-platform v0.1.5
   Compiling lock_api v0.4.11
   Compiling elf v0.7.4
   Compiling parking_lot_core v0.9.9
   Compiling utf8parse v0.2.1
   Compiling multimap v0.8.3
   Compiling regex-syntax v0.6.29
   Compiling regex-automata v0.1.10
   Compiling prost-build v0.12.3
   Compiling anstyle-parse v0.2.3
   Compiling risc0-binfmt v0.19.0 (/home/mint/risc0/risc0/binfmt)
   Compiling cargo_metadata v0.17.0
   Compiling risc0-circuit-recursion v0.19.0 (/home/mint/risc0/risc0/circuit/recursion)
   Compiling scroll_derive v0.11.1
   Compiling is-terminal v0.4.9
   Compiling overload v0.1.1
   Compiling colorchoice v1.0.0
   Compiling anstyle v1.0.4
   Compiling risc0-circuit-rv32im v0.19.0 (/home/mint/risc0/risc0/circuit/rv32im)
   Compiling anstyle-query v1.0.1
   Compiling docker-generate v0.1.3
   Compiling risc0-build v0.19.0 (/home/mint/risc0/risc0/build)
   Compiling anstream v0.6.4
   Compiling nu-ansi-term v0.46.0
   Compiling env_logger v0.10.1
   Compiling scroll v0.11.0
   Compiling matchers v0.1.0
   Compiling lazy-regex-proc_macros v2.4.1
   Compiling sharded-slab v0.1.7
   Compiling tracing-log v0.2.0
   Compiling erased-serde v0.3.31
   Compiling typetag-impl v0.2.13
   Compiling thread_local v1.1.7
   Compiling inventory v0.3.13
   Compiling strsim v0.10.0
   Compiling plotters-backend v0.3.5
   Compiling ciborium-io v0.2.1
   Compiling half v1.8.2
   Compiling downcast-rs v1.2.0
   Compiling plain v0.2.3
   Compiling clap_lex v0.6.0
   Compiling clap_builder v4.4.11
   Compiling goblin v0.7.1
   Compiling rrs-lib v0.1.0
   Compiling ciborium-ll v0.2.1
   Compiling plotters-svg v0.3.5
   Compiling typetag v0.2.13
   Compiling tracing-subscriber v0.3.18
   Compiling lazy-regex v2.5.0
   Compiling bonsai-sdk v0.5.0 (/home/mint/risc0/bonsai/sdk)
   Compiling risc0-zkvm-methods v0.19.0 (/home/mint/risc0/risc0/zkvm/methods)
   Compiling clap_derive v4.4.7
   Compiling crypto-bigint v0.5.5
   Compiling itertools v0.10.5
   Compiling bincode v1.3.3
   Compiling num-derive v0.4.1
   Compiling cast v0.3.0
   Compiling same-file v1.0.6
   Compiling walkdir v2.4.0
   Compiling criterion-plot v0.5.0
   Compiling clap v4.4.11
risc0-zkvm-methods-guest: Starting build for riscv32im-risc0-zkvm-elfm-sys(build), risc0-circuit-recursion-sys(build), protobuf-src(build), risc0-zkvm-methods(build), zstd-sys(build)
risc0-zkvm-methods-guest: error: could not execute process ` -vV` (never executed)
risc0-zkvm-methods-guest:
risc0-zkvm-methods-guest: Caused by:
risc0-zkvm-methods-guest:   No such file or directory (os error 2)
error: failed to run custom build command for `risc0-zkvm-methods v0.19.0 (/home/mint/risc0/risc0/zkvm/methods)`

Caused by:
  process didn't exit successfully: `/home/mint/risc0/target/release/build/risc0-zkvm-methods-58b921e67529646c/build-script-build` (exit status: 101)
  --- stdout
  Building guest package risc0-zkvm-methods.risc0-zkvm-methods-guest
  cargo:rerun-if-env-changed=RISC0_SKIP_BUILD
  Using rustc:
  cargo:rerun-if-env-changed=RISC0_RUST_SRC
  Building guest package: cargo build --target riscv32im-risc0-zkvm-elf
  cargo:rerun-if-env-changed=RISC0_BUILD_DEBUG
warning: build failed, waiting for other jobs to finish...
warning: cxx/step_verify_bytes.cpp: In function ‘risc0::Fp risc0::circuit::recursion::step_verify_bytes(void*, void (*)(void*, const char*, const char*, const risc0::Fp*, size_t, risc0::Fp*, size_t), size_t, size_t, risc0::Fp**)’:
warning: cxx/step_verify_bytes.cpp:33:10: warning: unused variable ‘mask’ [-Wunused-variable]
warning:    33 |   size_t mask = steps - 1;
warning:       |          ^~~~
warning: cxx/step_verify_bytes.cpp:32:28: warning: unused parameter ‘ctx’ [-Wunused-parameter]
warning:    32 | Fp step_verify_bytes(void* ctx, HostBridge host, size_t steps, size_t cycle, Fp** args) {
warning:       |                      ~~~~~~^~~
warning: cxx/step_verify_bytes.cpp:32:44: warning: unused parameter ‘host’ [-Wunused-parameter]
warning:    32 | Fp step_verify_bytes(void* ctx, HostBridge host, size_t steps, size_t cycle, Fp** args) {
warning:       |                                 ~~~~~~~~~~~^~~~
warning: cxx/step_verify_bytes.cpp:32:71: warning: unused parameter ‘cycle’ [-Wunused-parameter]
warning:    32 | Fp step_verify_bytes(void* ctx, HostBridge host, size_t steps, size_t cycle, Fp** args) {
warning:       |                                                                ~~~~~~~^~~~~
warning: cxx/step_verify_bytes.cpp:32:83: warning: unused parameter ‘args’ [-Wunused-parameter]
warning:    32 | Fp step_verify_bytes(void* ctx, HostBridge host, size_t steps, size_t cycle, Fp** args) {
warning:       |

This is likely fixed with:
git lfs install
git lfs pull

I think this has been resolved in 0.20, re-open if this is still failing.

authors: caiyesd flaub


text:
cleaning up docs directory

Resolves #758

Put up a PR to this branch that I think should fix the CI issue: https://github.com/risc0/risc0/pull/885

I won't be on github much next week; I'm gonna pass this back to @tzerrell to take over the line

source: gharchive/pull-request

license_type: permissive

license_source: github-api


text:
The virtual address space is not specified

The defalut start address is 0x10000 for gcc to compile non-PIE, but we couldn't find any related information in the documentation.
We find that the first related commit in gnu-toolchain is in 2016, but no relevant information mentioned in commit log.
The virtual address space is specified in the psabi of i386, x86-64 and mips.

So it may be necessary to document the virtual address space.

@jrtc27 the detailed information is supplemented.

There are no restrictions therefore there is nothing for us to document. Larger virtual address space extensions keep being added for RV64 (Sv57 being the latest) and we don't want to create headaches like exist on x86 where the ABI is initially 48-bit but then LA57 comes along and needs to be supported somehow. The default start address is toolchain-specific and sometimes also OS-specific.

source: gharchive/issue

repo: riscv-non-isa/riscv-elf-psabi-doc


text:
Added the ability to select a single test from a sute of test for

Added the ability to pass a set of FLAGS to the target, via a command
line variable to make RISCV_TARGET_FLAGS
Added the ability to select a single test from a suite of tests for compilation and execution

Lee - can you get someone to review this. Perhaps Allen

BTW - will need to be rebased on the upstream.

I'd like to ensure that this is (or can be made) compatible with riscof
On Thu, Oct 31, 2019 at 6:35 AM Jeremy Bennett notifications@github.com
wrote:

BTW - will need to be rebased on the upstream.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-compliance/pull/71?email_source=notifications&email_token=AHPXVJUXHMGIDNMUX2FXGW3QRLNL3A5CNFSM4JAQZ4OKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECXZLHQ#issuecomment-548378014,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJRK5WL5BZQOY3MONMDQRLNL3ANCNFSM4JAQZ4OA
.

Allen.
What?
We cannot stop usability enhancements of the current framework while we start discussing future evolution.
Riscof is not something we need to be compatible with.
Riscof is something that might fulfil our future requirements when we agree them.
So, please lets not stop evolving the current framework. (You have heard of the Osborne effect?)
Thnx
Simon

On 31 Oct 2019, at 13:11, Allen Baum notifications@github.com wrote:
I'd like to ensure that this is (or can be made) compatible with riscof
On Thu, Oct 31, 2019 at 6:35 AM Jeremy Bennett notifications@github.com
wrote:

BTW - will need to be rebased on the upstream.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-compliance/pull/71?email_source=notifications&email_token=AHPXVJUXHMGIDNMUX2FXGW3QRLNL3A5CNFSM4JAQZ4OKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECXZLHQ#issuecomment-548378014,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJRK5WL5BZQOY3MONMDQRLNL3ANCNFSM4JAQZ4OA
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

It's a moot issue, since it should work. I certainly have no objection to
be having a method to select a specific test instead of the whole suite - I
think its a good idea.
On Thu, Oct 31, 2019 at 1:40 PM Jim Straus notifications@github.com wrote:

Allen.
What?
We cannot stop usability enhancements of the current framework while we
start discussing future evolution.
Riscof is not something we need to be compatible with.
Riscof is something that might fulfil our future requirements when we
agree them.
So, please lets not stop evolving the current framework. (You have heard
of the Osborne effect?)
Thnx
Simon

On 31 Oct 2019, at 13:11, Allen Baum notifications@github.com wrote:
I'd like to ensure that this is (or can be made) compatible with riscof
On Thu, Oct 31, 2019 at 6:35 AM Jeremy Bennett <notifications@github.com
wrote:

BTW - will need to be rebased on the upstream.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<
https://github.com/riscv/riscv-compliance/pull/71?email_source=notifications&email_token=AHPXVJUXHMGIDNMUX2FXGW3QRLNL3A5CNFSM4JAQZ4OKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECXZLHQ#issuecomment-548378014
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AHPXVJRK5WL5BZQOY3MONMDQRLNL3ANCNFSM4JAQZ4OA

.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-compliance/pull/71?email_source=notifications&email_token=AHPXVJTWLJ7CGVAAHLIQ5ULQRM7FTA5CNFSM4JAQZ4OKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECZFWSI#issuecomment-548559689,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJTQMKLJSBQ5D26CVULQRM7FTANCNFSM4JAQZ4OA
.

Since this is reviewed, I am happy to merge once the conflicts are addressed.

Just to add.. RISCOF allows selecting of specific tests as well.

Abandoning this pull request will re-submit

repo: riscv/riscv-compliance


text:
vector: Define vtype to be a required assembler field

vtype settings are all partially required assembler fields. LMUL, tail behavior, and mask behavior have been defined to be optional at some point in the history of the spec. However, omitting tail and mask behavior was previously deprecated for vset* instructions. For consistency, a default LMUL should also be deprecated.
Additionally, the LLVM assembler does not support default args for the vset* instructions.

Thanks.  The NOTE didn't seem necessary to me--the history isn't terribly important, and in any case this document isn't authoritative about the assembly syntax.  So I manually merged the assembly changes via 75e857da51db157814f67e465c7262ae0a74c277.

Thank you!

authors: aswaterman charlie-rivos

repo: riscv/riscv-isa-manual


text:
imm value range of vsleu.vi

In 12.7 note.

The vsleu.vi range is 0 to 15 (and (~0)-15 to ~0)

Does it mean the value range of imm is 0 to 15? If so, why only use 4 bits instead of 5 bits?

0 to 15 (and (~0)-15 to ~0) means 0 to 15 and 2^N-16 to 2^N-1, where N is the width of the argument.  It's 32 distinct values, hence 5 bits.  I believe it's written this way because the arguments are unsigned, and so writing -16 to 15 would be confusing in a different way.

The immediate is sign-extended to SEW bits in the same way for all instructions, which leads to some of the unsigned operations having less useful ranges in some cases.

authors: aswaterman davetw kasanovic

repo: riscv/riscv-v-spec


text:
Test case for idiosyncrasy when [rd] is x0

Can we consider including a test case to characterize the idiosyncratic behavior of an implementation when an amoxxx.w instruction's destination register rd is the zero register, x0?
In case of real-world example of FE310, this idiosyncratic nature has to do with pipeline hazards, and the lack thereof, when writing to the "dummy" register. See detailed explanation at Demonstrating AMO

@psherman42 thanks for the link to these tests. Generally ISA specifications do not delve on the implementation microarchitectures. This specification is not a good home for such references. I would suggest you provide this on isa-dev and on unpriv mail lists to educate a wider audience about your findings.

Closing this issue.

repo: riscv/riscv-zaamo-zalrsc


text:
fix(optimizer): support pushdown pk to storage scan

Add a new rule that maps null to true so that storage filter on pk can be pushed down.

it seems that filter-scan-1 is still not correctly applied, that the last query in the planner test is not pushed down?

fixed b/c we didn't insert data into the table

... and obviously there are some sub-optimal plans 🤪 like two a > x and always false condition not eliminated.

fixed b/c we didn't insert data into the table

Yes, in CBO, if a table is empty, then any plan is possible because all of them have zero cost...

repo: risinglightdb/risinglight


text:
bug: incorrect wildcard handling in LIKE clause compared to pg

Describe the bug
When we handle wildcard (i.e. _) in the LIKE clause, our behavior is inconsistent compared to pg.
To Reproduce
In real PG
postgres=# create table test_table(name varchar);
CREATE TABLE
postgres=# insert into test_table values('test_table');
INSERT 0 1
postgres=# select * from test_table;
    name
------------
 test_table
(1 row)

postgres=# select * from test_table where name like 'test_table';
    name
------------
 test_table
(1 row)

postgres=# select * from test_table where name like 'test\_table';
    name
------------
 test_table
(1 row)

In RisingWave:
dev=> create table test_table(name varchar);
CREATE_TABLE
dev=> insert into test_table values('test_table');
INSERT 0 1
dev=> flush;
FLUSH
dev=> select * from test_table;
    name
------------
 test_table
(1 row)

dev=> select * from test_table where name like 'test_table';
    name
------------
 test_table
(1 row)

dev=> select * from test_table where name like 'test\_table';
 name
------
(0 rows)

Expected behavior
When we execute select * from test_table where name like 'test\_table'; in RisingWave, we should get the same output as pg.
Additional context
When handling constant LIKE clause with wildcard, the behavior is consistent to pg.
dev=> select 'test_table' like 'test_table' as val;
 val
-----
 t
(1 row)

dev=> select 'test_table' like 'test\_table' as val;
 val
-----
 t
(1 row)

dev=> select name like 'test\_table' from test_table;
 ?column?
----------
 t
(1 row)

dev=> select name like 'test_table' from test_table;
 ?column?
----------
 t
(1 row)

Looks like a bug in filter instead of like implementation.

dev=> select 1 from test_table where 'test_table' like 'test\_table';
 ?column?
----------
        1
(1 row)

dev=> select 1 from test_table where name like 'test\_table';
 ?column?
----------
(0 rows)

Likely a visibility bug

It's a bug in RewriteLikeExprRule

repo: risingwavelabs/risingwave


text:
allow >1 paralellism for pubsub source to increase ingestion performance

more discussion can be found here: https://risingwave-labs.slack.com/archives/C0606NNR74P/p1714493567060129
In essence, it is hard to make pubsub source exactly-once and other products only provide at-least-once semantics too, so 1 parallelism only does not help anyways.
We should make it parallel.
cc: @fuyufjh

Is it possible to have a rough ETA? (not necessarily need to be done very urgently)
as we are about to have a call with the user


text:
feat(storage): file cache insert rate limit based on real write rate

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?

File cache insert rate limiter based on real write rate. This will fix the rate limitation if compression is enabled.
Use dependency foyer with version, instead of repository commit hash.

Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added test labels as necessary. See details.
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[ ] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

Relevant PR in foyer: https://github.com/MrCroxx/foyer/pull/221

Relevant PR in foyer: MrCroxx/foyer#221

Thanks @hzxa21 for attaching the related info. After this PR, RisingWave will use version to maintain foyer dependency. And foyer will follow SemVer Compatibility and provide release note.


text:
Colorized helmet indicators

@hougasian had an idea for having differing helmet colors for users accomplished with a custom font.
We'd probably want to incorporate the colors into the list of items as well (perhaps a helmet in front of each item, but lower opacity, with a currently in-use one with full opacity?).
The fluent configuration might look like (note the SetColor usages):
var options = new StuntmanOptions()
    .AddUser(new StuntmanUser("user-1", "User 1")
        .SetColor(StuntmanColors.Blue) // or, perhaps we can use https://msdn.microsoft.com/en-us/library/system.drawing.color(v=vs.110).aspx or something?
        .AddClaim("given_name", "John")
        .AddClaim("family_name", "Doe"));

// Optionally assign a user an access token.
options
    .AddUser(new StuntmanUser("user-2", "User 2")
        .SetColor("ccc") // or, permit "#ccc"
        .SetAccessToken("123")
        .AddClaim("given_name", "Mary")
        .AddClaim("family_name", "Smith"));

Screenshots?

After @hougasian re-designed the UI, we've decided to take a different direction.

authors: kendaleiv khalidabuhakmeh

repo: ritterim/stuntman

license: mit

license_source: bigquery


text:
live server proxy config

 I want to configure multiple paths like nginx, how to configure the live server.Thanks.

Multiple proxies doesn't support httpProxyServer

repo: ritwickdey/vscode-live-server


text:
live serves does not identify css file .

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please search GitHub for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request
[ ] Other: <!-- Please describe: -->

Current behavior

Expected behavior

Environment
Browser:

- [ ] Chrome (desktop) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] IE version XX
- [ ] Edge version XX

For Tooling issues:

- Live Server: <!-- Check which version is installed -->
- Platform:  <!-- Mac, Linux, Windows -->
- Visual Studio Code: <!-- `code --version` -->

Others

I identified the problem , it was the name of the file that needed to be style.css , it was naming .css


text:
Add support for Browser Preview. Fixes #343

PR Type
What kind of change does this PR introduce?
[ ] Bugfix
[x] Feature
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other: <!-- Please describe: -->

What is the current behavior?
This PR adds support for Browser Preview via a new setting, as described in #343
What is the new behavior?
Adds the ability to use Live Server with an in-editor browser.
Does this PR introduce a breaking change?
[ ] Yes
[x] No

Other information

Thank you so much :cupid:

🎉

@ritwickdey When will this get published?

Hi @auchenberg, I'm actully worrying about https://github.com/ritwickdey/vscode-live-server/issues/285 (issue for chokidar library). Last time I fix it by changing old fse binary manually (https://github.com/ritwickdey/vscode-live-server/issues/285#issuecomment-462732753).
And I don't know it'll work anymore.. (I don't have macbook). That's why I waiting for a diffrent solution.

authors: auchenberg ritwickdey


text:
.deb package does not contain systemd unit file

Hello! Thanks for your great work
I've just downloaded the 1.6.6 release (using the newly added .deb package  https://github.com/rivosinc/prometheus-slurm-exporter/pull/97)
It claims to use systemd by default:

You can download RPM or DEB versions from the Releases tab. The
packages are configured to use systemd to start and stop the service.

Which is nice, but the unit file doesn't seem to be included:
$ wget https://github.com/rivosinc/prometheus-slurm-exporter/releases/download/v1.6.6/prometheus-slurm-exporter_1.6.6_linux_amd64.deb

$ dpkg -c prometheus-slurm-exporter_1.6.6_linux_amd64.deb
drwxr-xr-x root/root         0 2024-09-15 06:59 ./usr/
drwxr-xr-x root/root         0 2024-09-15 06:59 ./usr/bin/
-rwxr-xr-x root/root   9588996 2024-09-15 06:59 ./usr/bin/prometheus-slurm-exporter
drwxr-xr-x root/root         0 2024-09-15 07:00 ./usr/share/
drwxr-xr-x root/root         0 2024-09-15 07:00 ./usr/share/prometheus-slurm-exporter/
drwxr-xr-x root/root         0 2024-09-15 07:00 ./usr/share/prometheus-slurm-exporter/templates/
-rw-r--r-- root/root       927 2024-09-15 06:59 ./usr/share/prometheus-slurm-exporter/templates/proc_traces.html

$

Howdy! Thanks for leaving a comment and catching that. We initially had systemd enabled by default, but decided to go without it by default. Here is the context as to why. In short, I use containers for development, testing, and deployment and it was cumbersome to use it in that capacity. We also have a lot of ways to deploy the exporter and I didn't want to make that choice for the user. We compromised by providing the docs and a template for systemd deployment. I'll fix
the readme :)

Ah perfect! Sorry for the confusion :-)

authors: abhinavDhulipala magnuslarsen

repo: rivosinc/prometheus-slurm-exporter


text:
Build with tsc, output to ./dist

Hey, this looks like a great library, particularly the schema translation.
On trying to use it I discovered that package.json seems to lack the correct build incantation. This PR changes the build script to tsc and the outDir to ./dist.

Hi @jedahu, thanks for your interest! I'm still very actively working on this so there are a lot of small API details that are still in flux. Hopefully in the next few weeks I'll reach the point where I'm ready to build & publish this, and I'll merge this in then if it makes sense.

I decided to go with tsup for building/bundling:
https://github.com/rjdellecese/confect/blob/ad6f3f4b6a916e7046f885f3d60c3832e896f490/package.json#L15

authors: jedahu rjdellecese

repo: rjdellecese/confect

license: ISC


text:
Update to cats 1

Based on #9 and just an alternative to that PR wrt dealing with the on method.
This PR removes on from the Hash trait, analogous to the PR that changed Eq.
See https://github.com/typelevel/cats/pull/1997/files#diff-b9ae61b01d1ca692312138c96011784dL28
and https://github.com/typelevel/cats/pull/1997/files#diff-b9ae61b01d1ca692312138c96011784dL72
BTW #9 looks fine to me too, but was just thinking that it may be the intention of radixtree to follow the structure of cats here.

Thanks for the PR. Sorry about not getting back to you earlier. Was on holiday with a strict afk policy called "four kids".
I have merged the PR from @swiesner-dlr . Regarding the hash, isn't there a hash typeclass somewhere in cats land these days anyway? The only reason I have my own hash typeclass in this library is that there was none in cats / algebra / ...
So if you want to replace the hash with the one from cats (cats.kernel.Hash ?) that would be very welcome.

Thanks for the PR. Sorry about not getting back to you earlier. Was on holiday with a strict afk policy called "four kids".

LOL, no problem at all, happy to see that the upgrade has been merged in.

I have merged the PR from @swiesner-dlr . Regarding the hash, isn't there a hash typeclass somewhere in cats land these days anyway? The only reason I have my own hash typeclass in this library is that there was none in cats / algebra / ...

Ah, I was wondering about that Hash typeclass. I'll have a look at replacing that.

@rintcius :+1: I just tried to get radixtree compile and pass tests after updating cats; I didn't know why on was gone.  I'd love to see a more idiomatic upgrade to cats 1.0, but I for my part haven't followed cats' development so closely as to understand what changes we need :)
But, to be honest, more than that I'd love to see a new release with Cats 1 :blush:  radixtree pins us to 0.9 currently, which blocks all sorts of newer releases of other libraries which require Cats 1.

@rklaehn I have created https://github.com/rklaehn/radixtree/pull/11 to replace Hash (and some methods from Instances)

authors: rintcius rklaehn swiesner-dlr

repo: rklaehn/radixtree


text:
Swap Modes between EDIT and LIVE and store programs

[x] EDIT goes from LIVE to EDIT mode
[x] LIVE goes from EDIT to LIVE mode (from command prompt)
[x] LIVE in live mode does nothing
[x] Line with line number in LIVE mode automatically goes to EDIT mode and inserts line into program
[x] Line without line number in EDIT mode automatically goes to LIVE mode and executes
[x] Line with line number in EDIT mode is added to program
[x] Line out of order in EDIT mode reorders on ENTER and puts cursor in right place
[x] EDIT  ensures line number in view -- puts cursor at line
[x] EDIT  works in EDIT mode command prompt
[x] LIST  works exactly like EDIT line number

Additional issues:

[ ] Swapping back to live is still producing strange multi-input results
[ ] Reveal Lines might be able to work better
[ ] Hitting enter on pasted lines in editor creates a bunch of blank lines
[ ] Pasting lines is problematic -- needs to process these as pasted(?)

repo: rlamorea/weBASIC

license: MIT


text:
Different colors for combinations of Debuffs?

I posted on CurseForge but wanted to post here for visibility.
Is there any way to do 1 color for a specific debuff, but a different color if 2 debuffs exist?
For instance: Enhancement Shamans want Flame Shock on targets and then want to Lava Lash targets to cause the debuff Lashing Flames so they deal more damage. So I'm attempting to have:
1 color for just flame shock
1 color for just lashing flame
1 color for both flame shock and lashing flame on same target.

Interesting concept. I might see if I can put together something for that.

This is now supported.

authors: jamby rljohn

repo: rljohn/kuinameplates-target-helper


text:
Switching or Pushing a state should be delayed

The problem is that when you call ScreenManager.switch or ScreenManager.push in a callback of a state, the other callbacks are delivered to the state you switched to, so for example if you were in a menu and in the mousepressed callback you switch to the game, the keypressed and textinput callbacks will be from the game state and not actually from the menu which is the state you were actually updating this frame.
This may be good for some use cases but is bad for others. HUMP handles this by halting the state which works like this: you are in the menu, in the mousepressed callback you switch to the game, the rest of the callbacks will be ignored until the update callback is called and the game gets updated, then the next frame you get the callbacks normally. I consider this bad behaviour since there are callbacks you are not handling correctly and it may lead to a black frame.
My alternative would be the following, delay the state switch until after the draw callback. In this way you guarantee that the current state will be active until the next frame, and only the last switching/pushing/popping operation will be valid
Different use cases probably demands different behaviours, so I wanted to start the discussion.
I use a delayed switch in my code, but I also have a public function that allows me to change the states immediately called performChange and should be used after a push, pop or switch to get an immediate switch

I already had problems with this myself in an earlier game so I'd like to implement this as well.
As with #1 I'm not sure when I'll get to it though.

You can check the code I wrote here. And if you want then I can create a PR

Feel free to open a PR for this one too. I'll try to review and test it this weekend 👍

@Positive07 I wanted to publish the new release just now, but I think there is a problem with our current approach of using the change variable.
What if the user wants to pop() two screens from the current screen? Imagine something like this: You have a game screen, the player opens an inventory screen and in that screen he opens an compare items screen. For the player it would be convenient to just press 'i' to close the inventory screen.
This wouldn't be possible with https://github.com/rm-code/screenmanager/commit/c27ea3d3ccbe68f8c36e07045ecf22d7de386443. But it's not a hard issue to fix. We could simply use a "queue" for the actions.
I'm thinking about something like this:
local changes = {};

...
function ScreenManager.switch( screen, ... )
    validateScreen( screen );
    changes[#changes + 1] = { action = 'switch', screen = screen, args = { ... } };
end
...

function ScreenManager.performChange()
    if #changes == 0 then
        return
    end

    for _, change in ipairs( changes ) do
        if change.action == 'pop' then
            pop();
        elseif change.action == 'switch' then
            clear();
            push( change.screen, change.args );
        elseif change.action == 'push' then
            push( change.screen, change.args );
        end
    end

    changes = {};
end

Would this make sense? Are you seeing problems with this approach?

The problem with that is that if you switch and then pop we have no way to know that we popped the last state and that an error should be raised.
So what about keeping a separate stack and switching it on draw or something like that?

repo: rm-code/screenmanager

license: Zlib


text:
Add IgnoreGroup support

Unlike what I previously thought, some AUR packages have groups (f.e. kodi-addon-pvr-hts is part of kodi-addons group). This information is correctly displayed in the AUR interface, thus it should be handle by pacaur.
Add support for the related IgnoreGroup option.
To do:

[x] patch cower to retrieve the Groups array from the RPC (done)
[x] implement Groups display in the --info package info view (0c344dbb81166d736a756b7bebacb8935274a48a)
[x] implement check for AUR targets that that are part of an IgnoreGroup (87c15c2b8b3f60a2df084bf54e7181c974a5a792)
[x] implement check for AUR packages dependencies that that are part of an IgnoreGroup (c8f96c0afa112ee2740500b3c025a99ba2b2b7fc)
[x] implement check for binary packages dependencies that are part of an IgnoreGroup (8c1dabb41a88a939ee7df55d199453a0fbd0107f)
[x] check multi-group implementation (package that belongs to more than a group) (2130f83e1a2f627dc6c1479067a17f671bc3f308)
[x] ensure local package take IgnoreGroup into account when upgrading (8e474b4709a341ee76cbc56ae54663e7235f848a)

This incidentally overrides the previous decision in #501.
See also #267 as an extra error can be easily trigerred by IgnoreGroup prompt.

I'll backport these changes to pacaur 5.0 when the whole issue is completed.

Done in above mentionned commits.

Backport completed and GetIgnoredGrps() documented.

repo: rmarquis/pacaur

license: isc


text:
Split package into small reusable parts

Hi @rmcaixeta , nice to see the effort around models of local anisotropy. I see that there is a lot of code duplication here where you copied solvers from GeoStats.jl and modified them to achieve what you wanted quickly. As we discussed over Zulip, the best way to maximize the impact is to split the package into small components that can be moved to GeoStatsBase.jl or Meshes.jl for greater reuse across the framework. After all, local anisotropy should be an option in the existing Kriging and simulation solvers, not completely separate solvers.
I am concerned that if we don't tackle this issue now we will just lose the opportunity to have a cohesive treatment of local anisotropy. The effort will be disconnected from the rest of the framework, will get outdated, and that is not a great outcome.

Thanks for registering that, @juliohm
This package was a lab for me to learn julia and more about local anisotropies implementation. The framework will get evolved with time, I'll keep it updated with GeoStats framework until that. I believe that after refactoring kriging for block estimation and cokriging, things will get simplified here too.
I understand that there are two parts to deal: kriging and rotation conventions.
For the first, I think one day it might be enough to pass just a LocalGeoData in the EstimationProblem; or a custom variogram object for kriging (with LocalAnisotropy embedded) and the rest will be natural. I'm not totally sure right now because it has been some time since I coded kriging part, but if variogram function for kriging matrices are built with a variogram function like γ(GeoData1, GeoData2, ind1, ind2) instead γ(point1, point2), it'd be possible to remove a lot a kriging code here.
For the second, I belive that ideal solution would be an extra package that deals with rotation conventions. Where anyone could add its own rotation convention rules and output rotation matrix, quaternions, reverse rotation matrix etc. But that might be a little bit challenging too, there are multiple ways of naming and structure conventions, as it is here or in Meshes might not be enough yet.

authors: juliohm rmcaixeta


text:
Links in the menu not taking user to the appropriate page section

Good job so far, @rmiyoyo, But your menu links should take the user to that section of the page.

Hi @rmiyoyo
Great Job 👍
I would like to suggest that you include a contributing coding partner to your readme file and also check the desktop menu hover effect to make it like the design.


text:
bump rustls from 0.19 to 0.23

bump rustls up to 0.23
update some deps
fix some clippys

Thank you for your work on RMQTT, but some checks did not succeed.

Thank you for your work on RMQTT, but some checks did not succeed.

this PR depends on #2 and #6
maybe you should reviews these 2 PRs first

authors: diablur rmqtt

repo: rmqtt/rmqtt


text:
Salvattore crashing in Safari

I get an error when appending elements in Safari browser, Chrome and Firefox are working properly,
Error details:
[Error] TypeError: 'undefined' is not an object (evaluating 'fragments[i].children.length')
next_element_column_index (salvattore.js, line 382)
append_to_next_fragment (salvattore.js, line 423)
forEach
append_elements (salvattore.js, line 422)
appendIndexImages (scripts.js, line 114)
... rest is Jquery crap

The data is loaded dynamically when user scrolls down the page, so this might cause the problem.
Edit
Managed to fix this problem by simply removing fragments[i].children.length from salvattore.js as the length was always 0 in my case anyways.

Since this is already in the source I assume this is fixed.

authors: MariusRumpf exaroth

repo: rnmp/salvattore


text:
Init firebase db once, avoid flickering view

Fixes #1230

Thanks @rnystrom!

authors: BasThomas rnystrom

repo: rnystrom/GitHawk


text:
Not opening on MacOS Mojave

I really like the idea of the application, but it simply isn't opening for me.

Sorry, didn't see it on my menu bar

repo: robbertkl/GamepadMenu


text:
Rewrite concrete_sections to prevent error in plastic (until bug fixed)

Generates the concrete sections using the CompoundGeometry.from_points() method to avoid the issue in #193.

Have made this a draft as this will probably be reworked once all the associated geometry issues are solved. Will create a new issue for the CompoundGeometry.from_points() method.

Hi @robbievanleeuwen,
I pulled the latest master after merging those two PRs and am looking at the concrete section stuff. Is this PR obsolete now or does it include other changes to the concrete_sections module? Let me know and I will be glad to assist!

Largely obsolete, but it does add top bars to concrete beams amongst a few small things. I'm happy to take this one to the finish line once the __sub__() method is fixed.

authors: connorferster robbievanleeuwen

repo: robbievanleeuwen/section-properties


text:
[plugin] adds clipboard plugin

The clipboard plugin adds a copy and paste alias that works in every environment.
Copy and paste
$ echo "foo" | copy
$ paste
foo

Copy from file
$ echo "foo" > document.txt
$ cat document.txt | copy
$ paste
foo

Paste to file
$ echo "foo" | copy
$ paste > clipboard.txt
$ cat clipboard.txt
foo

When tools are missing
No cliboard util found!
Please install one of the following utils:
   pbcopy
   xsel
   xclip
$

We'll add those as core functions, see #4254. Please close

@mcornella, that is great. Looking forward to it.

Thanks, if you think of something else to be considered don't hesitate to post it there.

authors: mcornella pjvds

repo: robbyrussell/oh-my-zsh


text:
Add documentation for pyenv plugin

Partially addresses #7175
Adds a README for the pyenv plugin. Plugin already has documentation on the wiki: https://github.com/robbyrussell/oh-my-zsh/wiki/Plugins#pyenv

Thanks!

authors: joeratt mcornella


text:
jdk 11 support

See travis CI for build failures with jdk11.  We should get this working with jdk 11

Closing as fixed via #105

repo: robert-bor/CSVeed


text:
Release 0.99 to PyPi

Currently pip install easygui gives version unusable with Python 3.
Seems that the fixes are already commited. Please release current state to PyPi. Even if it has some bugs left, it's still better than 0.98.

Agreed, would be great to get it released, especially with this bug in the current public version.
cc @zadacka

@robertlugg - do you want to make an official v0.99 tag, and I'll update the version on PyPi?

Hi @zadacka, are you happy with the code quality?  I have no reason to suspect a problem but I haven't tested it.  If you are OK, I can just tag it.  Otherwise I need to dedicate some time this weekend to build my confidence in it.

@robertlugg (and for visibility to the others) we'll wait until the planned changes are made before making the v0.99 tag and releasing to PyPi. I'm almost done with moving house now, and can turn this around quickly when needed!

I have advanced quite a lot in develop. New demos for buttonbox, new tests, better support for callbacks, big refactoring, hotkeys in lowercase, message is centered, choices can be expressed in many new ways... Tested in linux, 2.7 and 3.5.
I would like you try it, and if possible run botton_box_demos.py and test_buton_box.py on other platforms.
But I would't wait to push current master to PyPi, maybe under v0.98.1 tag

Please release a 0.98.1 update - the incompatability with Python 3 is REALLY a show-stopper!
Thanks, Thomas

Six months seems like a long time to leave a broken module up on PyPi

I have made the release (I hope I did it right, it is my fist time): @zadacka Can you update to Pypi?

Will do! Should be able to update this tomorrow evening (UK time). Thanks @Juan
Sorry for the brevity - Sent from Mobile
On Thu, Jan 5, 2017 at 5:31 PM, Juan José Denis Corrales notifications@github.com wrote:
I have made the release (I hope I did it right, it is my fist time): @zadacka [https://github.com/zadacka] Can you update to Pypi?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub [https://github.com/robertlugg/easygui/issues/113#issuecomment-270704632] , or mute the thread [https://github.com/notifications/unsubscribe-auth/ADV8ofG656mxPHUbBd1MEC_vw3ovXotpks5rPSjZgaJpZM4KRvCt] .

I just tried pip3 install --upgrade pip ..no luck, the package is still from june

Updated on PyPi now. Tested locally with a pip install pypi --upgrade and I get v0.98.1
Is everyone else okay with this?

Hi. After upgrading to Python 3.6.0 and re-installing Easygui just now from PyPi, I always get this error on any widgets:
File "C:\Users\antor\AppData\Local\Programs\Python\Python36\lib\gettext.py", line 206, in _expand_lang
loc = locale.normalize(loc)
AttributeError: module 'locale' has no attribute 'normalize'

I don't seem to be able to make it work in 2.7.12.

import easygui
easygui.egdemo()
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'module' object has no attribute 'egdemo'

0.98.1 easygui.egdemo() works fine for me in 2.7.8 and 3.6.0

Okay, not so good on the upgrade then.
I'll revert the version on PyPi when back at the computer and then work on fixing it for Python 2.x and Python 3.x. Thanks very much for the feedback, all, and apologies for the abortive release.
Sorry for the brevity - Sent from Mobile
On Fri, Jan 6, 2017 at 10:00 PM, Juan José Denis Corrales notifications@github.com wrote:
I don't seem to be able to make it work in 2.7.12.
import easygui
easygui.egdemo()
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'module' object has no attribute 'egdemo'
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub [https://github.com/robertlugg/easygui/issues/113#issuecomment-271020709] , or mute the thread [https://github.com/notifications/unsubscribe-auth/ADV8oT2ha1_2JXs7dImenmIeDB1yQBi_ks5rPrmZgaJpZM4KRvCt] .

actually would please not remove 0.98.1. It works fine for me (that is on Linux)

Huh, strange.
Juan, Anton - change of plans. I'll try to reproduce your problems before reverting. Dirk - thanks for checking.
Sorry for the brevity - Sent from Mobile
On Fri, Jan 6, 2017 at 10:11 PM, alexander.zawadzki@gmail.com alexander.zawadzki@gmail.com wrote:
Okay, not so good on the upgrade then.
I'll revert the version on PyPi when back at the computer and then work on fixing it for Python 2.x and Python 3.x. Thanks very much for the feedback, all, and apologies for the abortive release.
Sorry for the brevity - Sent from Mobile
On Fri, Jan 6, 2017 at 10:00 PM, Juan José Denis Corrales notifications@github.com wrote:
I don't seem to be able to make it work in 2.7.12.
import easygui
easygui.egdemo()
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'module' object has no attribute 'egdemo'
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub [https://github.com/robertlugg/easygui/issues/113#issuecomment-271020709] , or mute the thread [https://github.com/notifications/unsubscribe-auth/ADV8oT2ha1_2JXs7dImenmIeDB1yQBi_ks5rPrmZgaJpZM4KRvCt] .

Ok, I completely reinstalled Python 3.6.0, and this error is now gone. My version is 0.98.1 now, and everything works fine.

I uninstalled and installed easygui and... everything looks fine!

Also don't forget to check out my enhancements, in develop.

pip install works fine on mac os x (sierra) and windows 7; Python 3.6
Cheers.

authors: aivarannamaa antorix dirkpetersen dmcnich gbaman jjdenis robertlugg spyoungtech thomas-haslwanter zadacka

repo: robertlugg/easygui