Better Token and contract info

In EtherDelta you can click on a token symbol and get a popup with extra info:

Also you can change to previous contracts with a dropdown, in case you want to withdraw tokens from previous versions of contracts.

Some of this stuff could be useful in Maker Market, especially the token info, because there's some weird ones like the GNT wrapper that could benefit from the added information.

It should be related to what @ramos-j mentioned in Rocket Chat:

followthechain 6:52 PM
what does "clearing broker" mean? actually, what is a broker and how does it work? (I hope/suppose it's a simple explanation)
mariano.conti 6:53 PM
basically, what it says here: https://github.com/makerdao/token-wrapper
github.com
makerdao/token-wrapper
Contribute to token-wrapper development by creating an account on GitHub.
"Deposits must be done via a "broker" due to lack of "pull" functionality on G"
followthechain 6:54 PM
history of deposits show a duplicate for my last deposit (probably because 2 tx were involved: the first, and the clearing broker)
followthechain 7:01 PM
hm... I didn't like it as just that comment in the code. There's no actual explanation on the text above the code snippet. I still don't know why the broker, or how it works. For instance: I'd assume ETH also doesn't have a pull functionally, and yet WETH doesn't need a broker.
Is it a contract that establishes a specific relationship between my address and the wrapper? If so, are gas costs negligible?


ENH: Ability to not shuffle masters connection

The Connection component also supports load balancing and failover between masters just as it does between slaves.

The Connection component supports load balancing and failover between slaves. When performing a read query for the first time, the Connection component will randomly pick a slave and try connecting to it. If the slave is found "dead", it will try another one.

Please, add ability to disable shuffling of masters, so they will be tried in the defined order.
Additional info

Q
A

Yii version
2.0.10

@Vovan-VE would you like to submit a PR?

Merged into 2.0.11.


Wrong flags in Usage helper text

I was trying to manually run wmi_exproter.exe with custom options, because I wanted the port to listen at 9100 (like node_exporter).
However, the flag listed in the command-line usage wasn't working, issuing the error flag provided but not defined: -addr:
PS C:\Program Files\wmi_exporter> .\wmi_exporter.exe -addr ":9100"
flag provided but not defined: -addr
Usage of C:\Program Files\wmi_exporter\wmi_exporter.exe:
  -collector.iis.app-blacklist string
        Regexp of apps to blacklist. App name must both match whitelist and not match blacklist to be included.
  -collector.iis.app-whitelist string
        Regexp of apps to whitelist. App name must both match whitelist and not match blacklist to be included. (default
 ".+")
  -collector.iis.site-blacklist string
        Regexp of sites to blacklist. Site name must both match whitelist and not match blacklist to be included.
  -collector.iis.site-whitelist string
        Regexp of sites to whitelist. Site name must both match whitelist and not match blacklist to be included. (defau
lt ".+")
  -collector.logical_disk.volume-blacklist string
        Regexp of volumes to blacklist. Volume name must both match whitelist and not match blacklist to be included.
  -collector.logical_disk.volume-whitelist string
        Regexp of volumes to whitelist. Volume name must both match whitelist and not match blacklist to be included. (d
efault ".+")
  -collector.net.nic-blacklist string
        Regexp of NIC:s to blacklist. NIC name must both match whitelist and not match blacklist to be included.
  -collector.net.nic-whitelist string
        Regexp of NIC:s to whitelist. NIC name must both match whitelist and not match blacklist to be included. (defaul
t ".+")
  -collectors.enabled string
        Comma-separated list of collectors to use. Use '[default]' as a placeholder for all the collectors enabled by de
fault (default "cpu,cs,logical_disk,net,os,service,system")
  -collectors.print
        If true, print available collectors and exit.
  -log.format value
        Set the log target and format. Example: "logger:syslog?appname=bob&local=7" or "logger:stdout?json=true" (defaul
t "logger:stderr")
  -log.level value
        Only log messages with the given severity or above. Valid levels: [debug, info, warn, error, fatal] (default "in
fo")
  -telemetry.addr string
        host:port for WMI exporter. (default ":9182")
  -telemetry.path string
        URL path for surfacing collected metrics. (default "/metrics")
  -version
        Print version information.

So I found out that it needed to use two hyphens (--addr ":9100") instead of one (-addr ":9100"), for every option.
So I think a fix is needed in the Usage text.

Hm, no, the flag is not -addr, but -telemetry.addr. I'm surprised --addr would work, did it actually start listening on that port, or was the flag ignored?
There is a problem with using dots in flags when executing from Powershell, though, which is unfortunate. It stops parsing at the dot, so you need to do "-telemetry.addr" ":9100" if starting from Powershell.

On testing on my system, I cannot get --addr to be accepted. What version are you using?

Sorry, I inserted the wrong text here (I tested a lot of options).
here is the correct one (-telemetry.addr):
PS C:\Program Files\wmi_exporter> .\wmi_exporter.exe -telemetry.addr ":9100"
flag provided but not defined: -telemetry
Usage of C:\Program Files\wmi_exporter\wmi_exporter.exe:
  -collector.iis.app-blacklist string
        Regexp of apps to blacklist. App name must both match whitelist and not match blacklist to be included.
  -collector.iis.app-whitelist string
        Regexp of apps to whitelist. App name must both match whitelist and not match blacklist to be included. (default ".+")
  -collector.iis.site-blacklist string
        Regexp of sites to blacklist. Site name must both match whitelist and not match blacklist to be included.
  -collector.iis.site-whitelist string
        Regexp of sites to whitelist. Site name must both match whitelist and not match blacklist to be included. (default ".+")
  -collector.logical_disk.volume-blacklist string
        Regexp of volumes to blacklist. Volume name must both match whitelist and not match blacklist to be included.
  -collector.logical_disk.volume-whitelist string
        Regexp of volumes to whitelist. Volume name must both match whitelist and not match blacklist to be included. (default ".+")
  -collector.net.nic-blacklist string
        Regexp of NIC:s to blacklist. NIC name must both match whitelist and not match blacklist to be included.
  -collector.net.nic-whitelist string
        Regexp of NIC:s to whitelist. NIC name must both match whitelist and not match blacklist to be included. (default ".+")
  -collectors.enabled string
        Comma-separated list of collectors to use. Use '[default]' as a placeholder for all the collectors enabled by default (default "cpu,cs,logical_disk,net,os,service,system")
  -collectors.print
        If true, print available collectors and exit.
  -log.format value
        Set the log target and format. Example: "logger:syslog?appname=bob&local=7" or "logger:stdout?json=true" (default "logger:stderr")
  -log.level value
        Only log messages with the given severity or above. Valid levels: [debug, info, warn, error, fatal] (default "info")
  -telemetry.addr string
        host:port for WMI exporter. (default ":9182")
  -telemetry.path string
        URL path for surfacing collected metrics. (default "/metrics")
  -version
        Print version information.

Using  --telemetry.addr it works:
PS C:\Program Files\wmi_exporter>
PS C:\Program Files\wmi_exporter> .\wmi_exporter.exe --telemetry.addr ":9100"
time="2017-07-06T20:37:40Z" level=info msg="Enabled collectors: logical_disk, net, os, service, system, cpu, cs" source="exporter.go:191"
time="2017-07-06T20:37:41Z" level=info msg="Starting WMI exporter (version=0.2.5, branch=master, revision=175c54acf13aee43592120ad0567257f01684dc1)" source="exporter.go:202"
time="2017-07-06T20:37:41Z" level=info msg="Build context (go=go1.8, user=appvyr-win\\appveyor@APPVYR-WIN, date=20170627-07:30:21)" source="exporter.go:203"
time="2017-07-06T20:37:41Z" level=info msg="Starting server on :9100" source="exporter.go:206"

Well, I think that the problem with using dots in flags when executing from Powershell should be at least present in the Usage text, it would prevent a lot of trouble IMO.
Thanks!

I've considered if we should actually just change the flags. The current ones were initially copied from node_exporter, but the gains from having a similar pattern are probably quite small.
It should be noted that this is only a problem in powershell, though. No other command line parser in Windows is affected.

hello @carlpett
I confirmed the problem with powershell.
IMO this PowerShell "problem" could be stated in the Usage text as a warning to the user.
Thanks!

I agree with @carlpett we could simply change the flags to get rid of this issue.


Specifying backends via config

Right now it is only possible to specify a backend via keyword argument.
I think, that it would be a nice feature to implement basic mix config for this task.
Something like:
use Mix.Config

config :hammer, Hammer,
   backend: Hammer.Backend.ETS

I think this would be a good line of investigation, maybe for a version2, api-breaking release.
Can we do it without making hammer an OTP application?

Can we do it without making hammer an OTP application?

I am quite sure that it is possible. Here's an example: https://github.com/samueljseay/recaptcha

Done in v2.0.0


Should the checked-in TUF root be V1 or later?

Description

See https://github.com/sigstore/sigstore/blob/main/pkg/tuf/repository/root.json#L142, the V2 TUF root. This root did not have a recorded and publicly documented signing ceremony. Should we switch to the V1 TUF root? It adds one extra network call to GCS when updating the root, but this seems negligible. I think that should be what we form the root of trust from.
@asraa

We had actually wanted to embed the latest trust root, not even V2.
I personally don't think it's necessary since it's still verifiable to load in the root from V1 if you wanted to trust it. But the problem is, earlier roots aren't even TUF compliant. V3 started using TUF compliant expires, so chaining from older roots may not make sense for every client, whereas distributing the latest trusted root in a trusted binary does.

i.e. our trust base is the cosign binary. If you don't trust the cosign binary, you're in a much worse situation.

That's a good point about the TUF compliance. Thanks!


Fix payment details status conversion

Issue: https://github.com/SecureApiGateway/SecureApiGateway/issues/1597
Fixed payment details status conversion.

not needed anymore


shortened modified names by certain characters in the package names

hi, i have not been able to test the tool fully yet, because we get strange results when package names contain german characters like ä ö ü. are the names only displayed wrong in the list and can it still be used normally?

btw. the app crashes when clicking into the empty list after launching the app (v3.3.3)

Thanks for the heads up.  Crash will be easy to fix.  Handling the special characters looks to be a bit more challenging. It seems the name returned from the API for the /packages endpoint differs from what is returned from /packages/id.  For example:
packages endpoint returns (expected results):

packages/id/1945 yields:

Within the app log I see:
[ViewController.fetchPackageList] Packages to replicate: ["̈öü.pkg"]
It's like the a character is replaced with a backspace.
Note, if I copy from a locally stored file it looks ok.
[ViewController.fetchPackageList] Packages to replicate: ["äöü.pkg"]
[ViewController.fetchPackageList] sourcePackageRecord: ["checksum": "", "name": "äöü.pkg", "size": "14904", "hashType": "MD5"]

Can't say for sure if this is/relates to the issue yet.


UI is broken in Internet Explorer

Something about the layout styling is not happy in Internet Explorer.

I fixed the layout styling to be more IE compatible, but since IE doesn't support TextEncoder and some other handy things, I've unfortunately decided that I currently don't have time to support the browser.


Hero images wider than 3:2 aspect ratio tile in mobile layout

The hero images are designed to work optimally at 2:1 aspect ratio for the desktop layout, but they suddenly switch to 3:2 layout below a certain window width. For images that are 2:1 ratio, they image starts to repeat beneath the first instance of it.
The right solution is probably to make 2:1 the ratio for all sizes.

This is being taken care of as part of the big image reworking in #7, so I'm closing this as a duplicate.


Brok and Sindri Dup bug

Both NPCs seek out wanted items (weapon/tool and rune stone) and they will sometimes pick up the same item, resulting in a duplication. Issue originating in PickUpWantedGoal

May have been resolved due to fine tuning of AI and navigation. Will continue testing to see if issue persists.

Testing and have not seen this come up again. Assume resolved.


If ConflictingLocksError is thrown on the backend during an IPC call rethrow it on the frontend

consumers of itwinjs-core may wish to display a user-friendly message on the frontend involving the ConflictingLocks interface.
Potentially relevant work item: https://github.com/iTwin/itwinjs-backlog/issues/1072#issuecomment-2196966663
About maybe a way we can avoid having to do this for each type of error we may end up throwing.

I think this approach is heading in the wrong direction. We should not create any subclasses of Error, and certainly no new ones. Testing for typeof is problematic and unnecessary. Errors should be an interface, as I proposed earlier.
BTW, I realize terminology is difficult, but "lock conflict" is confusing. Conflicts are what you get if you don't use locks. The error here must be "lock is in use", right?

I think this approach is heading in the wrong direction. We should not create any subclasses of Error, and certainly no new ones. Testing for typeof is problematic and unnecessary. Errors should be an interface, as I proposed earlier.
BTW, I realize terminology is difficult, but "lock conflict" is confusing. Conflicts are what you get if you don't use locks. The error here must be "lock is in use", right?

Since the conflictinglockserror passes IModelHubStatus.LockOwnedByAnotherBriefcase as its errorNumber, the message ultimately contains "Lock is owned by another briefcase".
Im guessing you meant instanceof? The imodels-clients repo will start throwing this error class during acquireLocks, so I assume that the instanceof check would pass in that case?
I agree we can't just keep creating subclasses of error, but I assumed switching over to something more uniform would have to be a breaking change for 5.0. I've been thinking about this problem in the context of a singular ITwinError interface as you suggested as well, in the workitem that I linked in the description.

Maybe "AlreadyLocked" would be better than "ConflictingLock"?

Maybe "AlreadyLocked" would be better than "ConflictingLock"?

Yes, that error makes more sense to me. Locks are either available or "in use" (the distinction is that shared locks block exclusive locks). I'd suggest "LockInUse" or "LockNotAvailable". The problem is that Conflicts come during Merge operations, that's why I was confused when I saw this PR.

I agree we can't just keep creating subclasses of error, but I assumed switching over to something more uniform would have to be a breaking change for 5.0.

It would be breaking to attempt to change existing subclasses of Error, but not if you're making up a new class. I suggest this be the first use of ITwinError and we never support Error subclasses "spanning" processes.

I've been thinking about this problem in the context of a singular ITwinError interface as you suggested as well, in the workitem that I linked in the description.

Since the conflictinglockserror passes IModelHubStatus.LockOwnedByAnotherBriefcase as its errorNumber, the message ultimately contains "Lock is owned by another briefcase".

This will only be useful if we give the "Moniker" of the lock holder (so the localized message will be "Element is in use by @joeSmith"), right? Hopefully the IMS team and IModelHub are working on that?

One last point, Locks lock Elements. When we refer to "locks" in error messages, that will confuse users - they only know about Elements. From their perspective the Element is locked.
[N.B. there is some mystery about locking Models - we really obtain the lock on its modeled element. Also the "schema lock" is really a lock on the root subject Element.]

I agree with most of @kabentley's sentiments. I think this discussion belongs on the issue, but he lacks access to it.
The proposed error interface looks like this:
export interface ITwinError {
    namespace: string;   // Localization namespace
    errorKey: string; // unique key for error, within namespace
    message: string; // explanation of what went wrong. (Should provide some format for localization, like ITwinLocalization.getLocalizedKeys but the opposite way)
    metadata?: LoggingMetaData;
}

This is great for being able to present meaningful information to the user. Software can recognize the unique combination of namespace+errorKey and react to specific errors if it needs to. It will not, however, have access to additional details like the list of unavailable locks.

This will only be useful if we give the "Moniker" of the lock holder (so the localized message will be "Element is in use by @joesmith"), right?

If the only error details available are encoded into the localizable string then all of the actionable details must be encoded into it. An operation can require multiple locks held by multiple different people, for example. That could make for a long, ugly user-facing error message.
Presumably ITwinError must include an object containing variables to replace placeholders in the localized message. e.g., "Element is in use by ${lockOwner}". Only the frontend can do the substitution because only it knows the user's locale.
Relying on namespace+errorKey as the "error code" may prove fragile. For example, we may need two different errorKeys for the "lock unavailable" error, depending on whether one or multiple locks are not held. Or, we may decide in the future to rephrase an error such that it requires different formatting (e.g., takes a different number of variables), necessitating a new errorKey to avoid breaking frontends that are using an older version of the localizable error message. Suddenly my catch statement block stops recognizing the error.
If we want software to be able to do anything with these errors, then we would effectively be making the localization keys an untracked part of our public API.

I'll share my thoughts from an email thread that requested ConflictingLocksError.
I feel like I want to localize errors on the Frontend. It is because Frontend is aware of the context - error messaging depends on the workflow the user was attempting. I mean, the same ConflictingLocksError could be translated differently (just random examples):

"Cannot edit iModel – user X is currently editing”
"Cannot synchronize changes – user X is currently pushing changes”

Translating errors on the Backend (returning a key) assumes that an error is always directly translated to the same user facing text - I don't think that is true in general. That will end up feeling "dull" and lack flexibility (limiting UX).

This will only be useful if we give the "Moniker" of the lock holder (so the localized message will be "Element is in use by @joesmith"), right? Hopefully the IMS team and IModelHub are working on that?

From what I understood, since the ConflictingLocks interface is a part of the error message, it would be used to see the userid of who owns the briefcaseId and and then query the hub's 'users' endpoint to get information about the user.
My suggestion on the issue is to add another field 'extraData' whose type is driven by the namespace + errorKey (Note I only know how to do this if we combined namespace and errorkey). In the ConflictingLocks case, extraData would be of type ConflictingLocks[]. See playground. This would give consumers compile time errors if we decided to change the type ConflictingLocks for some reason.
This extraData would allow consumers to specialize the message they show to users if they so desire. If they saw no need to, they'd be able to use our fallback message.
I don't think this solves the problem Paul brings up of our messages potentially needing to change formats, but maybe we'll see a need for changing message formats less if consumers can make their own message using the data provided in the 'extraData' field?

This extraData would allow consumers to specialize the message they show to users if they so desire.

This will encourage bad patterns of not caring and doing proper localization, because the responsibility won't be on the app developers, e.g. "it will be handled by the platform".
It seems awkward to me that the Backend needs to deal with localization. It doesn't even deliver the localization files, "how will it know" what keys exist? The Backend has no idea of what is happening on the Frontend - how can it provide a UX friendly error message?
Also, what about application defined errors? Can we get a mechanism to pass those to the Frontend?

This will encourage bad patterns of not caring and doing proper localization, because the responsibility won't be on the app developers, e.g. "it will be handled by the platform".

Isn't providing this extraData putting it on the app developers to create a message as they see fit? Or do you mean having a message to fallback to will encourage bad patterns? I figured it might be wasteful to force every single app to implement their own error message if we can provide a default that works just fine. I imagined app developers noticing a message they don't like and iteratively making custom ones.

I think there is some confusion about my comments. There are 3 separate topics here:

Error subclasses. We should not create any (new) subclasses of Error and certainly we should not attempt to propagate subclasses between processes as is introduced in this PR. Instead, add/test fields on an instance of Error.
Lock Terminology. The term "conflict" should not be used to refer to lock contention. Also, locks are for Elements, so terminology about locks should refer to the element they gate. Lastly, the "lock in use" exception should contain the identity (in the form of a username/moniker, not email) of the lock holder. Without that, no message to the user will be helpful.
The ITwinError interface. It should use two strings to differentiate the cause of the error (namespace and errorName) that replaces the problematic errorNumber in BentleyError. The combination of those strings may be presumed unique - and that's all they convey.

I can't see the rest of the proposal for ITwinError, but the comment above about message containing localization strings isn't right. The "message" field is for programmers and logs, not for users. However, the exception should contain enough information so that programmers CAN create a localized message in their application (e.g. the "inUseBy" field for the lock contention error). One way to do that would be to use the namespace/errorName fields as localization keys. That would require some extra consideration when the message has to include other data (e.g. the moniker) so localization will have to be case by case. Note that all Localization headaches are the same as if we continued the subclassing-Error approach.

Instead, add/test fields on an instance of Error.

In such case, how would we communicate to application developers what error fields to expect and of what type? If we rely on applications discovering Error fields themselves, it sounds like we could not really change them once we add them, since it is possible they added code that relies on those fields and they will not get any compiler errors like they would if we changed names/property types on a class.

I can't see the rest of the proposal for ITwinError, but the comment above about message containing localization strings isn't right. The "message" field is for programmers and logs, not for users.

Could you give an example of what the message field would look like? When you initially proposed it here, you mentioned that the message should be an

"explanation of what went wrong. (Should provide some format for localization, like ITwinLocalization.getLocalizedKeys but the opposite way)"

I'm having trouble picturing what this means. GetLocalizedKeys does the below:
getLocalizedKeys("string with %{MyKeys.Key1} followed by %{MyKeys.Key2}!"") // returns "string with First Value followed by Second Value!".

In such case, how would we communicate to application developers what error fields to expect and of what type? If we rely on applications discovering Error fields themselves, it sounds like we could not really change them once we add them, since it is possible they added code that relies on those fields and they will not get any compiler errors like they would if we changed names/property types on a class.

Use an interface for your Error.


Support UUID --> log ID parsing

Goal: support parsing the UUID during GET calls to determine which log to query (with defaulting for the 0 case here). This would require two changes:

[ ] During upload of an entry, the UUID created should include a parseable log ID. For example, if the active log has log ID 163, the UUID might look like: 163-d2f305428d7c222d7b77f56453dd4b6e6851752ecacc78e5992779c8f9b61dd9, where the number before the - separator is the log ID.

[ ] Then during handling of a GET request for a particular UUID, the log ID can be easily determined and the request routed accordingly.

@dlorenc @bobcallaway Does this sound right to you based on the design?

Perhaps a nit, but the term "log ID" is already in use in rekor,  trillian and RFC6962 - so I would rather we call it "partition ID" or "shard ID".

Goal: support parsing the UUID during GET calls to determine which log to query (with defaulting for the 0 case here). This would require two changes:

[ ]  During upload of an entry, the UUID created should include a parseable log ID. For example, if the active log has log ID 163, the UUID might look like: 163-d2f305428d7c222d7b77f56453dd4b6e6851752ecacc78e5992779c8f9b61dd9, where the number before the - separator is the log ID.

Am I correct in saying that in order to handle the case for backward compatibility) if no shard ID is specified, default to the current log (i.e. shard 0)?

[ ]  Then during handling of a GET request for a particular UUID, the log ID can be easily determined and the request routed accordingly.

@dlorenc @bobcallaway Does this sound right to you based on the design?

yes, this aligns with what I had thought of in the design doc

+1, this all sounds right!

Note: make sure UUID will never use the separator char we are using.


Print only seems to render portion of screen for printing rather than whole document

Describe the bug
When trying to print out the demo's, print only seems to render the portion of the screen for printing rather than the whole document.
Reason for trying this: My aim was to see whether a report can be printed to PDF.
To Reproduce
From browser choose print, then preview or print.
Expected behavior
The whole document should be printed.

OS: Windows 10
Browser: Chrome
Version 84.0.4147.125

Thank for the issue! I can repro this.
This is because we're adding overflow CSS and height: 100% to the main HTML element, which we can remove to allow this in the next release.
In the longer term, we are considering adding renderers for both PDF and email, so you can do this a bit more elegantly. Any suggestions about how you would like this to work with more interactive elements would be much appreciated.
Thanks!

Was this fixed or is there intention to fix this? I still get the single page render result when I attempt to print it ^^;

Any update on this? I too am still getting single-page render results.


typechecker not correctly identifying receiver for import aliases

Relating to https://github.com/ceylon/ceylon/issues/5892#issuecomment-172906719, with the following code in a module named simple:
import simple {
    o { oHash = hash }
}

object o {}

shared class X() {
    hash => 99;
    print(oHash); // error (also, should not print 99!)
}
// Inherited member may not be used in initializer of X: hash is inherited by X from Identifiable

the error indicates that the typechecker thinks oHash refers to X.hash, and not o.hash. The declaration for the base expression is value Identifiable.hash => Integer.

Note that the X.hash definition and 99 stuff is extra info, to help explain the issue and for a future backend test.

I disagree that this is a bug. o does not have its own definition of hash, so o.hash actually refers to Object.hash. So it seems to me that this behavior is correct.

@gavinking I don't think that's right:

It would be confusing (aside from shadowing), for oHash to have a different value depending on its scope or what one of its containers might satisfy, and
It's not the right type. Identifiable.hash's type is Integer(Identifiable), but type type of both o.hash and oHash is Integer.

I don't think it makes sense for import aliases of this sort to be read as defining a fallback receiver instance if one can't be found in the current scope." The import clearly reads to indicate that o should be the receiver.

It's not the right type. Identifiable.hash's type is Integer(Identifiable), but type type of both o.hash and oHash is Integer.

Well, no. You didn't write ``Identifiable.hash, you wrote oHash, as if you would have written hash, which does have type Integerinside the body ofX`.

It would be confusing

I agree it's a pretty strange corner case. Probably we should just disallow it, marking the import statement itself as an error.

I agree it's a pretty strange corner case. Probably we should just disallow it, marking the import statement itself as an error.

So it retroactively becomes an error if, in a new version of o, the author decides to no longer override hash?

@jvasileff well, yes.

Yuck! That would certainly be an unintended consequence.

From a practical perspective, I don't see the relevance of whether the object has overridden the member. I may want to:
import com.example.charsets {
    utf8 { utf8Encoder = encoder }
}

despite utf8.encoder being inherited from its supertype (not overriden).
I'd actually lean towards removing this feature rather than have it only work sometimes, depending on implementation details of the object that are irrelevant (and generally unknown) to the importer.

BTW, because I think this was a very valid point:

It's not the right type. Identifiable.hash's type is Integer(Identifiable), but type type of both o.hash and oHash is Integer.

Well, no. You didn't write ``Identifiable.hash, you wrote oHash, as if you would have written hash, which does have type Integerinside the body ofX`.

It's outside the body of X that I believe properly indicates the type of oHash, which is always Integer.
When used inside of X, its type shouldn't be re-interpreted to be Integer(Identifiable) to make room for the automatic application of X's this.
If we were allowed to import \Io.hash instead of \io.hash (and have that mean Integer(Identifiable) and not Integer(\Io)), perhaps it would look like an Integer inside X, but, it would be Integer(Identifiable) outside.

I think what @gavinking means is that import Foo { f = g } aliases the Foo.g member into Foo.f, allowing you to use it as such. When you're in the body of a Foo it works, and when not, you have to qualify it with a Foo instance qualifier. Somewhat unintuitively, it does not let you refine f, you have to refine g, but that's because you can use it both as f and g, it doesn't hide the original name.
Now, it seems that with toplevel object members, the import bar { f = g } does a second thing, which is to give you a toplevel name f which is bound to the member bar.g, regarless of whether the member is declared or inherited. This is why we could do import utf8 { decode = decode }. Notice that for some reason import utf8 { decode } it not allowed (contrary to intuition), so it feels like the "member alias as toplevel" feature is not complete.
What happens in your example is that the alias oHash = hash seems to be defined not just for o, but for Identifiable. And so within a scope where Identifiable is inherited, oHash refers to thatscope.hash, or this.hash in this example.
It could be consistent with the first case of member alias, iff it were defined as import Identifiable {oHash = hash} but I believe that users expect the alias to only be defined in subtypes of the imported declaration. In this case, only subtypes of o. So within the body of X, oHash should unambiguously refer to o.hash.

The import clearly reads to indicate that o should be the receiver.

Yes, that goes with what I said above "users expect the alias to only be defined in subtypes of the imported declaration." In this case there's no subtype of o so it's only valid within it and for receivers of that type, and if missing targets this particular receiver.

At least on my system, the type-member import import Foo { f = g } seems even more limited than you describe. It does indeed seem very different from value-member imports.

f can never be used w/o a qualifier. Even inside Foo it needs to be this.f
The qualifier must be exactly Foo. For example, if we import ceylon.language { Identifiable { hc = hash } }, usage has to be like: (object {} of Identifiable).hc.

Ah, didn't realise that. Well, all the more consistent with our expecation that oHash refers to o.hash.

@FroMage's [interpretation])(https://github.com/ceylon/ceylon/issues/6445#issuecomment-241983082) is my interpretation, yes.

f can never be used w/o a qualifier. Even inside Foo it needs to be this.f
The qualifier must be exactly Foo. For example, if we import ceylon.language { Identifiable { hc = hash } }, usage has to be like: (object {} of Identifiable).hc.

Well, indeed these two things might be bugs. Perhaps we should open issues for them.

The interpretation or the conclusion?

So within the body of X, oHash should unambiguously refer to o.hash.

Heh, just found this ancient TODO at TypeDeclaration:452:
    //TODO: does not handle aliased members of supertypes

So @7d69600fffb703fd05a38b19d100cbcf32fa0a05 makes the error go away. But that's not enough, because the backend would also need to change it's actual behavior. Also the solution is kinda fragile and slightly breaks the scoping rules of the language.
From an implementation point of view I would much prefer the solution which makes it illegal to import an inherited member, but I can see how that makes member imports less useful.
Anyway, I'm going to throw this minor bug in the "too hard" basket for now.


SAM-3161 - Improve code for return of getSubPoolSize

This was what I wanted to add onto #3989

clean!


[asset] add Savings CELO - sCELO

i am guessing some instructions are missing in the README.
Does this require running yarn build so it autogenerates some files?

Does this require running yarn build so it autogenerates some files?

HI Zviad-- yes it does. Apologies

Does this require running yarn build so it autogenerates some files?

HI Zviad-- yes it does. Apologies

You might also want to note that this requires at least Node v14. It doesn't work with earlier versions of Node.

You might also want to note that this requires at least Node v14. It doesn't work with earlier versions of Node.

Thanks for letting me know-- I'll do that. Longer term I'll probably just add some kind of GitHub Action to automatically run this script after a merge


Simplify controllers

Some controllers need to be refactored. For example, UserController and VacationController have a lot of code. This code should be moved to the respective service.
See how this is done in the other controllers.

This looks like a cool app. Is there any way I could help contribute? I am proficient in React and have a little knowledge about Spring boot. Thank you.

This looks like a cool app. Is there any way I could help contribute? I am proficient in React and have a little knowledge about Spring boot. Thank you.

Thank you for showing interest.
You can try to start with this issue. For reference you can see the previous commits on the other controllers.
We are going to add more issues soon.
Also, we are starting the front-end development soon (on another public repository) for which we will use Angular.
Don't hesitate to ask if you have any question.

awesome! Thank you. I will work on this first thing Saturday.


feat: add HIP-904 frictionless airdrops definitions

Description:

Updating proto definitions as specified in HIP-904.
Notes for reviewer:

Checklist

[ ] Documented (Code comments, README, etc.)
[ ] Tested (unit, integration, etc.)

Added owner's account id to TokenRejectTransactionBody as agreed in design doc discussion.

Moving to draft as we'll want to split the changes in separate PRs.

@MiroslavGatsanoga I think this can be closed. Thanks


Choose Hyperparameters for Different Experiments

The genetic algorithm has a large number of hyperparameters which need to be chosen for the hypotheses in #19:
Operations:

Crossover method/whether to crossover
Crossover probability
How many pokemon to crossover (can be random each time)
Whether to mutate
Whether to mutate inverse to fitness instead of using a simple probability
Mutation probability
How many pokemon to mutate (can be random each time)

Battle/fitness:

fitness function to use (currently standardised win ratio vs BT model)
match-up function (i.e. all vs all vs graph-based sampling)
N of teams
N of matches per team (if using graph-based sampling)
N of battles per match

General:

N of generations

Some considerations:

The role of crossover is to swap good 'genes' between chromosomes
Crossover probability is typically useful to keep high. In our context, you can also think of it as determining how many times a team needs to be selected before you'd expect it to be kept in the next population unaltered (e.g. a crossover prob of 50% would mean you need to select a team twice before you'd expect it to appear in the next generation unaltered, ignoring mutation probability)

Too high, you miss out on potentially syngergystic pairings. Too low, you fail to properly explore the space

The role of mutation is to maintain genetic diversity. Too high, you start losing good genes too often. Too low, you can accidentally remove important sources of diversity early without a way to add them back in
Some 'typical' values I found online were 0.95 for crossover probability and 0.01 for mutation probability

My memory of where discussions got to is:
1v1

Selection as normal via fitness
'Crossover' is meaningless here, should be turned off
Mutation may be important, especially as if Pokemon are removed early (and just got unlucky), this is the only route back in
But: we may want to focus on mutating worse pokemon out, so use mutation inverse to fitness

2v2

Selection as normal via fitness
'Crossover' has a role here, as teams can do well for two reasons:

One of the pokemon is especially good (we want to crossover)
Two pokemon synergise well (we wouldn't want to crossover)

We'd want a lower crossover probability than 6v6, but not a low one either because of this. Could start with 0.75
Mutation prob of 0.01 to start with

6v6

Selection as normal via fitness
Crossover is likely v important here for searching the space
Could start with 0.95 (we could try and be more nuanced, but I don't have a strong take)
Mutation prob of 0.01 to start with

General

If we want a large N of teams, then BT + graph sampling of matches will be important
Genetic Algo isn't necessary for 1v1, but 1v1 does offer a good test case for convergence towards the tiers
I would prioritise unique matchups over repeating matches, as with enough matches losses through bad luck shouldn't matter too much while new matchups offer more information

All in all, the goal here is to work out some initial arguments, and possibly to suggest we write these up into a set of config files (YAML or JSON) with a script able to take a config path argument. We should discuss possible hyperparams more

I don't have my notes with me from discussions during the week today, but I'll dig them up at some point and possibly edit this issue against them


rzup install fails with unhelpfull error on unsupported architectures

Is there an existing issue?

[X] I have searched the existing issues

Experiencing problems? Have you tried our Discord first?

[X] This is not a support question.

Description of bug
Following https://dev.risczero.com/api/zkvm/install from an Intel (x86) yields an expected but unhelpful error:
Error: No asset found for target: X86_64AppleDarwin

Ideally this error would also report what you should do (install the toolchain manually) .
Steps to reproduce
run rzup install on any device that does not have a build artifact present upstream.

Hey @nuke-web3, this error is coming up on an "Apple M1" computer. The target itself is incorrect.
(Here is the screenshot of my "About This Mac" window)

Thanks for reporting!
Strange as I know rzup detected x86 on your device...
Maybe a bug in: https://github.com/risc0/risc0/blob/824974bd158c29185b6c0583ba403d40ec5ff14f/rzup/src/utils/target.rs#L36-L54

This is the output of rzup -v install:
verbose: Detecting host target...
verbose: Detected target: x86_64-apple-darwin
verbose: Creating lockfile at path /Users/apple/.risc0/lock
verbose: Created temp toolchain filepath at /var/folders/4y/gw7mss5x66z3v9twsbt__1v80000gp/T/.tmpvxLSFN/tmp_r0_rust_toolchain.tar.gz
verbose: Getting toolchain release info from https://api.github.com/repos/risc0/rust/releases/latest
Error: No asset found for target: X86_64AppleDarwin

@avikalpg do you happen to have any overrides in place related to Rosetta?
What does these commands yield?
uname --all
rustup show

See these perhaps related threads:

cross-compilation

Here is the output of uname -a:
Darwin MacBook-Pro-5.attlocal.net 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:53:34 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T8103 arm64

And here is the output of rustup show:
Default host: x86_64-apple-darwin
rustup home:  /Users/apple/.rustup

installed toolchains
--------------------

stable-x86_64-apple-darwin (default)
1.77-x86_64-apple-darwin

active toolchain
----------------

stable-x86_64-apple-darwin (default)
(timeout reading rustc version)

Looks like you've got the x86 toolchain installed. This probably works on your machine due to Rosetta, but it's going to be a lot slower than just going native. It's possible you installed rustup during the period of time just after the M1 came out and before rustup had apple-silicon toolchain published.
You might try reinstalling rustup from scratch. Basically you need to have it show something like this:
$ rustup show
Default host: aarch64-apple-darwin
...

installed toolchains
--------------------
stable-aarch64-apple-darwin (default)
...

Aah, I see. Yes, that is very much possible. My M1 computer is pretty old (bought around the end of 2021) and I think I installed rust in mid-2022.
So, now I have updated my rustup. Here are the steps I followed:
rustup uninstall stable
curl --proto 'https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

And here is the output of the rustup show command:
Default host: aarch64-apple-darwin
rustup home:  /Users/apple/.rustup

installed toolchains
--------------------

stable-x86_64-apple-darwin (default)
1.77-x86_64-apple-darwin

active toolchain
----------------

stable-x86_64-apple-darwin (default)
rustc 1.82.0 (f6e511eec 2024-10-15)

So I still had to update the toolchains. So I ran these commands:
rustup toolchain uninstall stable-x86_64-apple-darwin
rustup toolchain install stable-aarch64-apple-darwin

And now the output of my rustup show is:
Default host: aarch64-apple-darwin
rustup home:  /Users/apple/.rustup

installed toolchains
--------------------

stable-aarch64-apple-darwin
stable-x86_64-apple-darwin (default)
1.77-x86_64-apple-darwin

active toolchain
----------------

stable-x86_64-apple-darwin (default)
rustc 1.82.0 (f6e511eec 2024-10-15)

I had to set the apple silicon toolchain as default:
rustup default stable-aarch64-apple-darwin

My rustup show now outputs:
Default host: aarch64-apple-darwin
rustup home:  /Users/apple/.rustup

installed toolchains
--------------------

stable-aarch64-apple-darwin (default)
stable-x86_64-apple-darwin
1.77-x86_64-apple-darwin

active toolchain
----------------

stable-aarch64-apple-darwin (default)
rustc 1.82.0 (f6e511eec 2024-10-15)

But I am still getting this output when I run rzup -v install:
verbose: Detecting host target...
verbose: Detected target: x86_64-apple-darwin
verbose: Creating lockfile at path /Users/apple/.risc0/lock
verbose: Created temp toolchain filepath at /var/folders/4y/gw7mss5x66z3v9twsbt__1v80000gp/T/.tmpeQhwaS/tmp_r0_rust_toolchain.tar.gz
verbose: Getting toolchain release info from https://api.github.com/repos/risc0/rust/releases/latest
Error: No asset found for target: X86_64AppleDarwin

I'm wondering what the output of file says for the rzup binary, it should say:
$ file $(which rzup)
/Users/x/.risc0/bin/rzup: Mach-O 64-bit executable arm64

It's possible that your shell is an x86 version of bash/zsh, which would cause the install script to detect your system as x86.

It's possible that your shell is an x86 version of bash/zsh, which would cause the install script to detect your system as x86.

Apologies for barging in like that on the conversation (I was actually browsing the issues in search for something unrelated), but yes, it was a common issue for folks running the Terminal.app via Rosetta when first Apple Silicon Macs came out, and then homebrew (and related) tooling would detect x86_64 rather than aarch64 as the CPU arch influencing installation dirs, etc. Anyway, the easiest test for the OP is to run
$ uname -m

If x86_64 is reported then the Terminal.app is still being run via Rosetta which can be disabled by navigating to /Applications/Utilities/ and then right-clicking on Terminal.app and selecting Get Info. There a toggle option is "hidden" Open using Rosetta. On the off-chance that this helps.


Ethan: Watch (?-i:DynamicNestedField)(?#pypi.org/project)

Ethan requests the watch of the watch_keyword (?-i:DynamicNestedField)(?#pypi\.org/project). See the MS search here and the Stack Exchange search in text, in URLs, and in code.

Rejected by cigien in Charcoal HQ. Reason: 'by request (it's the watch version of the pattern that's blacklisted)'


Add EUREC4A Intake catalogue

Insert URLs to the project here:
https://github.com/eurec4a/eurec4a-intake

[x] The projects is active, documented, open source licensed, shows usage from external parties and is directly targeting environmental sustainability. Find more details in the Contribution Guide.

All issues labeled as 'Good First Issue' of the project listed on OpenSustain.tech will be visible on ClimateTriage.com. This is a great way to welcome new community members to your project.
https://eurec4a.eu/
Note: License can only be found on Zenodo not on GitHub: https://zenodo.org/records/8422322

@observingClouds @d70-t


React-router 0.13 support

react-router/react-router.d.ts
to author(@mrk21). could you review this PR?
:+1: or :-1:?
check list

[ ] pass the Travic-CI test?

Hi @vvakame, @vasek17,
I think it's basically good, but there are some issues listed below:
Occurs the compile error when used react module instead react/addons module
Issue code:
test.ts
///<reference path='react/react.d.ts' />
///<reference path='react/react-addons.d.ts' />
///<reference path='react-router/react-router.d.ts' />

import React = require('react/addons');
import Router = require('react-router');

React.createElement(Router.RouteHandler, null);

$ tsc --module commonjs test.ts
test.ts(8,21): error TS2345: Argument of type 'RouteHandlerClass' is not assignable to parameter of type 'ComponentClass<any>'.

This issue does not occur when used not react/addons module but react module.
The reason is that defines only React.createElement() for ReactRouter Components on react internal module, and does not define on the react/addons internal module.
Therefore, we should add the codes shown below:
declare module "react/addons" {
  import ReactRouter = require("react-router");

  // for DefaultRoute
  function createElement(
    type: ReactRouter.DefaultRouteClass,
    props: ReactRouter.DefaultRouteProp,
    ...children: ReactNode[]): ReactRouter.DefaultRoute;

  // for Link
  function createElement(
    type: ReactRouter.LinkClass,
    props: ReactRouter.LinkProp,
    ...children: ReactNode[]): ReactRouter.Link;

  // for NotFoundRoute
  function createElement(
    type: ReactRouter.NotFoundRouteClass,
    props: ReactRouter.NotFoundRouteProp,
    ...children: ReactNode[]): ReactRouter.NotFoundRoute;

  // for Redirect
  function createElement(
    type: ReactRouter.RedirectClass,
    props: ReactRouter.RedirectProp,
    ...children: ReactNode[]): ReactRouter.Redirect;

  // for Route
  function createElement(
    type: ReactRouter.RouteClass,
    props: ReactRouter.RouteProp,
    ...children: ReactNode[]): ReactRouter.Route;

  // for RouteHandler
  function createElement(
    type: ReactRouter.RouteHandlerClass,
    props: ReactRouter.RouteHandlerProp,
    ...children: ReactNode[]): ReactRouter.RouteHandler;
}

Typo in RouteHandlerClass interface
- interface RouteHandlerClass extends React.ReactElement<RouteHandlerProp> {}
+ interface RouteHandlerClass extends React.ComponentClass<RouteHandlerProp> {}

Does not define the type definition of router context
ReactRouter has been added router context since 0.13; it's an alternative to existing State and Transition mixins.
Existing method:
var Foo = React.createClass({
    mixins: [ Router.State ],
    render: function () {
        var params = this.getParams();
        return React.DOM.div('test');
    }
});

New method:
class Foo extends React.Component<any,any> {
    static contextTypes = {
        router: React.PropTypes.func
    };
    render () {
        var router = this.context.router;
        var params = router.getCurrentParams();
        return React.DOM.div('test');
    }
}

In the above code, a type of this.context.router is any. Therefore, we should add the context type shown below:
declare module "react-router" {
    interface Context {
        makePath(to: string, params?: {}, query?: {}): string;
        makeHref(to: string, params?: {}, query?: {}): string;
        transitionTo(to: string, params?: {}, query?: {}): void;
        replaceWith(to: string, params?: {}, query?: {}): void;
        goBack(): void;

        getCurrentPath(): string;
        getCurrentRoutes(): Route[];
        getCurrentPathname(): string;
        getCurrentParams(): {};
        getCurrentQuery(): {};
        isActive(to: string, params?: {}, query?: {}): boolean;
    }
}

Thereby, we will be able to do type checking of router context:
class Foo extends React.Component<any,any> {
    static contextTypes = {
        router: React.PropTypes.func
    };
    render () {
        var router: Router.Context = this.context.router;
        router.getCurrentParams(); // OK
        router.getCurrentParams2(); // Compile error
        return React.DOM.div('test');
    }
}

Move the legacy type definition file to react-router/legacy/react-router-0.12.d.ts
We should follow react/react.d.ts, and move the legacy type definition file show below:
react-router
├── react-router.d.ts    # HEAD
├── react-router-test.ts # HEAD
└── legacy
     ├── react-router-0.12-test.ts
     └── react-router-0.12.d.ts

any updates?

@vasek17 how about this PR?

I merged #4898 .


Loading Spinner iOS

Hi, this project is just what I'm looking for so thanks!
On iOS (iPhone 6) the loading spinner appears to freeze. I'm using it to stream mp3's from the web. The spinner spins once or twice and then stops until the audio begins to play about 30 seconds later. On my android test device (galaxy S3) the spinner spins and audio begins to play after about 1 or 2 seconds.

Hmmm, I have an Android device too but mine seems to work as expected. How large are your audio files? Are your files hosted on Amazon or similar?

All files are hosted on Amazon S3 and about 20mb. Seems to work good on Android, it's iOS where I have the delay and the spinner freezes.

This module uses the Cordova Media plugin for playback. Apparently it does not support streaming of MP3 files, unless you use an M3U playlis I was told.  What type of URLs are you using? And are you using Cloudfront or Amazon Elastic Transcoder?

I'm just using a url like http://bucket.s3.amazonaws.com/path/to/my.mp3". I'm not using cloudfront or Amazon Elastic Transcoder.

I think the plugin will try to download the whole file before playback, so that may be the lag you are experiencing. I bet you can check that with Chrome Dev tools in the network tab.

Okay I'll look into that. Thank you for the info.

I created a m3u file with a single entry pointing to a mp3 on Amazon S3. I tested it with VLC media player to make sure it worked. Unfortunately it doesn't seem to work with this plugin. If I replace the track mp3 URL with the m3u URL nothing happens. The loading spinner just spins.
I found you forum discussion with ghenry22 that mentions the m3u. I can't seem to find any other information about m3u and Cordova media plugin. Did you incorporated ghenry22's fork of the Cordova Media plugin?

I remembered the Cordova Media Plugin is a dependency so I removed the official plugin and installed ghenry22's fork. I still was unable to use a m3u file. I tested on iOS and android. On iOS the error I see is:
Failed to initialize AVAudioPlayer: The operation couldn’t be completed. (OSStatus error<PHONE_NUMBER>.)
After searching this error I believe it means its an unsupported file format for AVAudioPlayer which I believe is what Cordova Media uses to play audio on iOS.
By the way, while I was changing versions of Cordova Media I noticed your documentation lists the following way to install it:
ionic plugin add org.apache.cordova.media
This gives a warning that to get the latest release it should be installed like:
ionic plugin add cordova-plugin-media

Maybe you should head over to that other thread on the Ionic forum and ask ghenry22 directly. He seems to have found a way to make it work. If you manage to make it work then I can make the necessary changes to this module if needed.

Okay will do. I submitted a pull request (my first one) for the readme on installing cordova media plugin. I'm a novice with this so hopefully that was helpful.


No spacing between the skill tags on the Teammates page

There is no vertical spacing between the skill tags, making it difficult for the user to read the skills.

I want to work on this issue under GSSoC22.

Go ahead @aashay-03

Please make sure you refer to the issue number # when you are making a pull request.
Please add screenshots and (or) screen recordings for your resolution of the issue in your pull request, in order to ensure your pr gets merged soon. This is highly recommended.


Epoundor/proposal

To ensure that pushes are always linted and formatted.

You could be able to automate it inside your editor, right ? Anyway, let's keep it

I don't understand


Add help methods to check if segment needs reprocessing

Add helper methods to check if a segment needs reprocessing by comparing its metadata with the table config and schema.
Right now, the checking and reprocessing logic are mixed together in ImmutableSegmentLoader.load() method. The helper methods added here will allow us to check consistency before conducting any real reprocessing that can be heavy. For example, when a segment doesn't need reprocessing, we can save all the upfront cost of preparing the data for reprocessing, like downloading some data from remote tier backend.
This PR hasn't changed the existing control flow yet. The next one will.
Description

Upgrade Notes
Does this PR prevent a zero down-time upgrade? (Assume upgrade order: Controller, Broker, Server, Minion)

[ ] Yes (Please label as backward-incompat, and complete the section below on Release Notes)

Does this PR fix a zero-downtime upgrade introduced earlier?

[ ] Yes (Please label this as backward-incompat, and complete the section below on Release Notes)

Does this PR otherwise need attention when creating release notes? Things to consider:

New configuration options
Deprecation of configurations
Signature changes to public methods/interfaces
New plugins added or old plugins removed

[ ] Yes (Please label this PR as release-notes and complete the section on Release Notes)

Release Notes

Documentation

Codecov Report

Merging #7898 (2ad1a9e) into master (fb12a50) will decrease coverage by 56.99%.
The diff coverage is 0.00%.

@@              Coverage Diff              @@
##             master    #7898       +/-   ##
=============================================
- Coverage     71.34%   14.35%   -57.00%
+ Complexity     4087       80     -4007
=============================================
  Files          1587     1544       -43
  Lines         82071    80392     -1679
  Branches      12267    12105      -162
=============================================
- Hits          58553    11538    -47015
- Misses        19550    67999    +48449
+ Partials       3968      855     -3113

Flag
Coverage Δ

integration1
?

integration2
?

unittests1
?

unittests2
14.35% <0.00%> (-0.10%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fb12a50...2ad1a9e. Read the comment docs.

I don't fully understand the optimization here. Looks like the new flow will be ImmutableSegmentLoader will call SegmentPReprocessor.needsPreprocess() and if this returns true, will the segment be pre-processed by the server during load. However, the code is using segment directory interface which seems to imply that segment exists on the server unless this is being done specifically for a custom/plugin implementation different from SegmentLocalFSDirectory ?
In that case I can see the point of just looking at the metadata (whether the column has index or not, whether column exists or not etc)

I don't fully understand the optimization here. Looks like the new flow will be ImmutableSegmentLoader will call SegmentPReprocessor.needsPreprocess() and ...

Thanks for the comments. Many of your observations are right. This refactoring is mainly driven by the need to make the logic related to segment loading also work with remote tier backend efficiently (a SegmentDirectory implementation different from SegmentLocalFSDirectory); and meanwhile make the logic easy to extend by assuming interface instead of a concrete local index dir.
In fact, it's BaseTableDataManager's addOrReplaceSegment() and reloadSegment() methods to be refactored to call the new needProcess() method. They'll handle cases where SegmentDirectory can be null. Both methods will also be refactored to work with interfaces (i.e. SegmentDirectory and SegmentDirectoryLoader) instead of directly assuming a local index dir.

rethinking the refactoring.


feat(ball): add ball system and refactor code

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


yarn check-audit not working

It seems that moving to yarn@3 has broken this feature

See https://github.com/naugtur/npm-audit-resolver/issues/57


DifficultySliderMultiplier is always 1.4 after reading a beatmap

Seems like the DifficultySliderMultiplier will be always the default one instead of reading the proper DifficultySliderMultiplier from the .osu beatmap file.
Right after I create the object Beatmap from a file, if I check the propery DifficultySliderMultiplier, it will say 1.4.

The reader was looking for DifficultySliderMultiplier, same with SliderTickRate. Both are fixed now. I'll update the dll for you.

Here you go :)

Thanks, now it works flawlessly :+1:


Create 0000-01-02-rrmehta2.md

Add new slide

My slide based on issue #2

My slide based on issue #2


Transfer of the repository

Could you please transfer the repository and PyPI project to me (mgorny on both)? It no longer works with new Sphinx versions, and we'd like to fix it. Since I don't think it's used outside of Gentoo, we'd like to effectively transfer it under Gentoo maintenance.

Ping.


Some links in build scripts don't exist

The link for the build script in "linux/linux" isn't available in the aports anymore (https://git.alpinelinux.org/aports/plain/testing/linux-edge)
EDIT: I also discovered that the patch file in "base/llvm" is missing too (https://reviews.llvm.org/file/data/fwstsxaybgq26x5dtdbg/PHID-FILE-pptlyffhoud7h2kme6qo/D100835.diff)

Should be fixed now


Some websites require enabling javascript

I reviewed my agent output and found that a website was not downloaded because the website required javascript.
📝 Information gathered from url
https://pubchem.ncbi.nlm.nih.gov/compound/apigenin: The given text does not
provide any specific information about the chemical structure and properties
of Apigenin. It primarily focuses on the requirement of enabling JavaScript
to use the PubChem website, which is an official site of the United States
government. It also emphasizes the importance of encryption and secure
transmission of information. Without additional information, it is not
possible to answer the question about the chemical structure and properties
of Apigenin.

I can think of two different approaches to solving this issue, but I am not sure which is the better option:

Enable javascript for all websites
Detect websites showing messages to enable javascript and retry with js enabled.
Includes No 2. and detect various other messages and handle them. Basically do the things the website requested and retry until the actual content is retrieved.

We're working on a different approach right now, stay tuned :)

@Di3mex try and pull latest version. we've added js support to scraping. See here: https://github.com/assafelovic/gpt-researcher/pull/151


Signup redirect url parameter

This works the same as the signin redirect. If a user was trying to access a page and gets redirected to sign in or sign up, after succeeding they will be redirected from where they came.
Since a user can only be redirected to either the signin or signup page, it is beyond the scope of this feature to pass the query parameter in the url to the other page when requested.

Coverage increased (+0.04%) to 95.62% when pulling 93260825c10ff5d1207fa365146d6ab04bf16ea8 on Rsgm:signup-redirect into 6cc09546e37ce9367889b4d04c240364dc3605cc on bread-and-pepper:master.

I just realized signin form sends the next field as a post field. I will close this and update signup to act more like that.

I added next as a post parameter. It reflects how signin works with redirect parameters. I didn't add much else, but I fixed a bug with the old one.
There really isn't a reason to send the redirect url as a post parameter. The post parameter comes from the initial url parameter, which gets sent through a post request anyway.
I am not sure why a few tests fail.

Coverage decreased (-0.04%) to 95.543% when pulling 4c038a00d602b1b0bf630efc4da59b78e69b1c60 on Rsgm:signup-redirect into 6cc09546e37ce9367889b4d04c240364dc3605cc on bread-and-pepper:master.

Coverage decreased (-0.04%) to 95.543% when pulling 4c038a00d602b1b0bf630efc4da59b78e69b1c60 on Rsgm:signup-redirect into 6cc09546e37ce9367889b4d04c240364dc3605cc on bread-and-pepper:master.

@Rsgm yeah, sending this redirect value additionally through POST form seems pretty odd at first glance. But after some thought I guess it is designed that way to make whole solution more robust against subtle errors/mistakes made often by developers.
Consider a case when userena user overrides "sing in" template with something like following:
<form action="/accounts/signin/" method="post">
{{form.as_p}}
{# ... #}
</form>

This way you could accidentally disable whole redirection feature by using action="/accounts/signin/" instead of leaving this attribute empty. Form would work OK but would not redirect to next as expected. The same would happen if you would like to use {% url your_sign_in_view %} template tag. By adding redirection url as a hidden form field (back from query string) we are able to cover few cases of such very subtle issues that are not always obvious.
I won't argue if silently dealing with such cases is bad or good. It is great that you choose the approach that is consistent with the one that we have already have in "sign in" flow because it will be less surprising to users.
Now back to the PR. I will try to reproduce errors we see on Travis in my local environment. I have tried already to rerun tests in Travis and I'm pretty sure it is not a random failure. Anyway, it is interesting that some tests fail only on py32-django17 and py32-django18. Have you tried to reproduce these errors in your local environment?

Thank you for the explanation. I guess I didn't know forms without an action use the current url. I agree, that is probably a good check to have.
As for the tests. I only tested it on 2.7 and 3+, since I knew Travis would check the rest. I will try on my machine with all the versions though.
I apologize for the coverage going down. I did add a test, but unit tests can't really reflect this functionality well.
Last thing. I wasn't sure if this would fit in the scope of this project, but there is no real way to do it from outside of the app. Hopefully others find it useful too.

The #535 was the reason of failures in CI and was stopping this PR from merging. Fortunately, it is finally resolved. Could you rebase your PR on current master so we can have it tested in Travis again?
When doing rebase you can also squash your changes in order to keep commit log more concise.

I apologize, I only just got around to fixing my branch. I updated this and my other previous merge request. Assuming everything passes, the previous request may need to be merged before this(I am certain how branches merge with the same commit).

Coverage decreased (-0.04%) to 95.543% when pulling 2f3521955886b278061efd3f3f910016832dc1c4 on Rsgm:signup-redirect into 7dfb3d5d148127e32f217a62096d507266a3a83c on bread-and-pepper:master.

Coverage decreased (-0.04%) to 95.543% when pulling 2f3521955886b278061efd3f3f910016832dc1c4 on Rsgm:signup-redirect into 7dfb3d5d148127e32f217a62096d507266a3a83c on bread-and-pepper:master.

The travis error is looks like it is failing trying to set up the environment. It also failed a different python/django version on my other pull request, #515.


Add support for logit_bias for OpenAI Chat models / support for cl100k_base tokenizer

Currently, lmql doesn't support logit bias-based constraints for openai/gpt-3.5-turbo and openai/gpt-4. However, the OpenAI documentation states that logit_bias is indeed supported by the API. The reason why it currently doesn't work might have something to do with the fact that these models use a different tokenizer, cl100k_base, which doesn't seem to be well documented. For example, for the "list of things not to forget when going to the sea" example, here's the current prompt generated by lmql:
{
  "model": "gpt-4",
  "max_tokens": 32,
  "temperature": 0.8,
  "user": "lmql",
  "stream": true,
  "logit_bias": {
    "16012": 100,
    "16598": 100,
    "24541": 100
  },
  "messages": [
    {
      "role": "user",
      "content": "A list of things not to forget when going to the sea (not travelling): \n- Sunglasses \n-  Ur \n- "
    }
  ]
}

However, tokens 16012, 16598 and 24541 in cl100k_base are "Urls", " Crusher" and ".getType", which explains why the model generates a completion "Ur". The solution might be to use the https://github.com/openai/tiktoken library:
>>> import tiktoken
>>> enc = tiktoken.get_encoding("cl100k_base")
>>> enc.encode("Volleyball")
[53, 35619, 4047]
>>> enc.encode("Sunscreen")
[31192, 8337]
>>> enc.encode("Bathing Suite")
[33, 44661, 21652]

And indeed using logit biases
{
    "53": 100,
    "31192": 100,
    "33": 100
}

I'm getting {"content":"Sun"}

Wow thanks, this is amazing news. Thanks for pointing it out. AFAIK this has not always been the case, especially early on the API was very limited, but we should definitely implement support now.
Thanks for the pointers. We already considered implementing support for tiktoken. I will have a closer look soon. In case you want to dive in, https://github.com/eth-sri/lmql/blob/main/src/lmql/runtime/bopenai/openai_api.py is where we implement the Chat API interface.

I tried adding the tiktoken tokenizer (see #25), but looks like something else is wrong for chat models (see screenshot in the PR). Let me know if you have any ideas!


Verify LRU stability during warmup

Previously, items were evicted as the item count approached capacity. This was not expected behavior, items should not be evicted until capacity is reached.
Eliminating the races during Cycle and Cycle warm have made this stable.

coverage: 98.598%. first build
when pulling c8c77d0bf6d4c3eeb7dc507711d53a89fdba503f on users/alexpeck/lruwarmup
into b027a68da862a83ff1ef100080278047e2efeeb6 on main.


Please confirm these before moving forward

[x] I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
[x] I have not been informed if the issue is resolved in a preview version of the winget client.

Category of the issue
Different install technology.
Brief description of your issue
Latest Firefox pushed version 132.0 (#179429) does NOT download latest Developer Edition 132.0.b6 (Correct URL) instead it downloads latest Stable Version 132.0.b4 (Wrong URL).
The mentioned architecture is x64, but the same applies to the others as well.
Steps to reproduce
winget install --id Mozilla.Firefox.DeveloperEdition

Actual behavior
winget install --id Mozilla.Firefox.DeveloperEdition

Found Firefox Developer Edition (en-US) [Mozilla.Firefox.DeveloperEdition] Version 132.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://download-installer.cdn.mozilla.net/pub/firefox/releases/132.0b4/win64/en-US/Firefox Setup 132.0b4.exe
██████████████████████████████  65.2 MB / 65.2 MB
Successfully verified installer hash
Starting package install...
Successfully installed

Expected behavior
winget install --id Mozilla.Firefox.DeveloperEdition

Found Firefox Developer Edition (en-US) [Mozilla.Firefox.DeveloperEdition] Version 132.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://download-installer.cdn.mozilla.net/pub/devedition/releases/132.0b6/win64/en-US/Firefox Setup 132.0b6.exe
██████████████████████████████  65.2 MB / 65.2 MB
Successfully verified installer hash
Starting package install...
Successfully installed

Environment
Windows Package Manager (Preview) v1.9.2411-preview
Copyright (c) Microsoft Corporation. All rights reserved.
Windows: Windows.Desktop v10.0.26100.2033
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.24.2411.0
Winget Directories
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads
Links
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale
Admin Setting                             State
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled
ProxyCommandLineOptions                   Disabled
DefaultProxy                              Disabled
Screenshots and Logs
No response

Since #182436 is merged, I'll assume this Issue is complete. If this is in error, please @ me and I'll reopen.

@stephengillie I think this is not yet fixed. 132.0 Mozilla.Firefox.DeveloperEdition (en) overrides Mozilla.Firefox (ja). It is different edition and different locale.
Firefox Developer Edition (x64 ja)                  Mozilla.Firefox.DeveloperEdition 131.0         132.0         winget

(1/12) 見つかりました Firefox Developer Edition (en-US) [Mozilla.Firefox.DeveloperEdition] バージョン 132.0
このアプリケーションは所有者からライセンス供与されます。
Microsoft はサードパーティのパッケージに対して責任を負わず、ライセンスも付与しません。
ダウンロード中 https://download-installer.cdn.mozilla.net/pub/firefox/releases/132.0b9/win64/en-US/Firefox%20Setup%20132.0b9.exe

I wish https://github.com/microsoft/winget-pkgs/pull/185183 fix this issue

https://github.com/microsoft/winget-pkgs/pull/185183 looks fixed this problem.
I could fix it with uninstalling Mozilla.Firefox and re-install Mozilla.Firefox again.
And I tested that installing Mozilla.Firefox.DeveloperEdition does not replace the installed Mozilla.Firefox.


Update OpenAPI docs

@justinjc curious if this is still a WIP

Ok re-running semaphore tests, don't like to approve pulls with failed tests.


rsync still mounts . to /vagrant even after SSHFS has mounted there

Hi,
This is related to the patch but I didn't know any place else to put this.
During reverse mounts (host to guest), Vagrant does not rsync to /vagrant if we have mounted a directory there via NFS/SMB (using type, "NFS/SMB"), but this is not the case when using vagrant-sshfs, because Vagrant still tries to rsync the directory on host to /vagrant even after SSHFS has mounted it.
This should not be the desired behavior, right?

Closed, stale repo, dustymabe/vagrant-sshfs does not have this issue.


Add anonymous type declarations

This issue is branching out of discussion in #17636, and largely intended to support that feature.
In the language as it stands today, this would look something like
type A<T> = ( type <U> = {value: U}; )<T>;

This is really not very useful. However, #17636 proposes type declaration overloading, which would allow type switching and filtering within the type system. Anonymous type declarations would allow for inline type switches, reducing the need for global type declarations, and support a further proposal that would alleviate the need for #6606, see #17641.
With type declaration overloads, these anonymous type declarations may look something like
type Foo<T> = {
    value: (
        type <U extends number> = {aNumber: number};
        type <U> = {aDefault: U};
    )<T>
};

For details of how the overloading works, see #17636.
Anonymous type declarations (ATDs?) should probably be allowed in interfaces too, such that Foo<T> above could be an interface.

I'm hugely in favor of this proposal. As noted in #17636, I would only allow overloading as part of this proposal, not on its own, to alleviate concerns with ordering and declaration merging.

More generally, we need support for generic values; i.e. the ability to add an arbitrary levels of type abstraction to any type expression. If I have the type Foo<T>, I should be able to declare const x: <A> Foo<A>, just as in other languages you can do forall a. Foo a, or forall a. forall b c. Foo a b c. Currently this is possible in a special cased form for function values, i.e. write const x: <T>(x: T) => <U>(u: U) => Foo<T, U>. I've tried to lay out a motivating example for this in #17574

@masaeedu
That's a really interesting point, and to be honest I'm not nearly experienced enough with the right languages to be able to process it super easily. Once I've got my head around it I'll have a think about how that could play nicely with the rest of the little network of suggestions that have fallen out of #17636.
Is that suggestion something you can see fitting in nicely alongside these others? Does it clash in any way, or make anything else redundant? Your wording posting here indicates that maybe you think #17574 would cover the requirement for this?

@TheOtherSamP No, the things you are suggesting (as far as I understand at least) seem like they would solve lots of my problems. I'm just going around trying to reference "prior art" concepts that are similar from other languages, so people involved can study those to get a feel for the tradeoffs involved and perhaps pick simpler, more general designs.

To put it another way, if we end up implementing this instead of #17574, I would still be able to encode "polymorphic values" using this feature. The two requests are more or less equivalent in power, just different in syntax.
However it subjectively "feels" more natural to me to simply express this feature as a generalization of generic functions. Just as we say "for all types T, a function that embeds T in an array" is <T> (x: T) => T[], we should be able to say "for all types T, a Fooer of Ts" is <T> Fooer<T>, and "a function that returns, for all types T, a fooer of Ts" is () => <T> Foo<T>. Syntax negotiable.

@masaeedu
That's interesting. As someone who doesn't have a background in type theory or the relatively obscure (well, ish) type-heavy functional languages like Haskell, that's pretty unintuitive for me. It may of course be really simple and easy once you get to play with a working example for two minutes. I suspect that I represent the majority of TypeScript users in that respect though.
Would you be able to provide a couple of little examples of side-by-side comparisons of the two approaches to some simple problems so we can do a more direct comparison?

Turns out internally these already exist, more related snippets in that checker.ts too big for Github search to check.

We now have conditional types, which seem to solve the use cases presented here.


🐛 BUG: Error: write EOF when running npx wrangler dev

Which Cloudflare product(s) does this pertain to?
Wrangler
What version(s) of the tool(s) are you using?
wrangler 3.81.0
What version of Node are you using?
Node.js v20.18.0
What operating system and version are you using?
Windows 11, Win32NT 10.0.22621.0 Microsoft Windows NT 10.0.22621.0
Describe the Bug
Observed behavior
I'm gong thru the getting started instructions from https://developers.cloudflare.com/workers/get-started/guide/. When I get to the point to run the npx wrangler dev command it gets an error. I see there is another similar issue. The last request on that was the version of the OS. I included that in the field above. Do you need any other information?
Expected behavior
Not sure. First time trying out Workers.
From the docs it looks like it would run a service that I could connect to via a browser.
Steps to reproduce
PS C:\Users\WDAGUtilityAccount> nvm install lts
Downloading node.js version 20.18.0 (64-bit)...
Extracting node and npm...
Complete
npm v10.8.2 installed successfully.
Installation complete. If you want to use this version, type
nvm use 20.18.0
PS C:\Users\WDAGUtilityAccount> nvm use lts
Now using node v20.18.0 (64-bit)
PS C:\Users\WDAGUtilityAccount> npm create cloudflare@latest -- my-first-worker
Need to install the following packages:
<EMAIL_ADDRESS>Ok to proceed? (y)

npx
create-cloudflare my-first-worker

──────────────────────────────────────────────────────────────────────────────────────────────────────────
👋 Welcome to create-cloudflare v2.30.0!
🧡 Let's get started.
📊 Cloudflare collects telemetry about your usage of Create-Cloudflare.
Learn more at: https://github.com/cloudflare/workers-sdk/blob/main/packages/create-cloudflare/telemetry.md
──────────────────────────────────────────────────────────────────────────────────────────────────────────
╭ Create an application with Cloudflare Step 1 of 3
│
├ In which directory do you want to create your application?
│ dir ./my-first-worker
│
├ What would you like to start with?
│ category Hello World example
│
├ Which template would you like to use?
│ type Hello World Worker
│
├ Which language do you want to use?
│ lang JavaScript
│
├ Copying template files
│ files copied to project directory
│
├ Updating name in package.json
│ updated package.json
│
├ Installing dependencies
│ installed via npm install
│
╰ Application created
╭ Configuring your application for Cloudflare Step 2 of 3
│
├ Retrieving current workerd compatibility date
│ compatibility date 2024-10-11
│
╰ Application configured
╭ Deploy with Cloudflare Step 3 of 3
│
├ Do you want to deploy your application?
│ no deploy via npm run deploy
│
╰ Done
────────────────────────────────────────────────────────────
🎉  SUCCESS  Application created successfully!
💻 Continue Developing
Change directories: cd my-first-worker
Start dev server: npm run start
Deploy: npm run deploy
📖 Explore Documentation
https://developers.cloudflare.com/workers
💬 Join our Community
https://discord.cloudflare.com
────────────────────────────────────────────────────────────
npm notice
npm notice New minor version of npm available! 10.8.2 -> 10.9.0
npm notice Changelog: https://github.com/npm/cli/releases/tag/v10.9.0
npm notice To update run: npm install -g<EMAIL_ADDRESS>npm notice
PS C:\Users\WDAGUtilityAccount> cd my-first-worker
PS C:\Users\WDAGUtilityAccount\my-first-worker> npx wrangler dev
⛅ wrangler 3.81.0
╭────────────────────────────────────────────────────────────────────────────────────────⎔ Starting local server...
╭──────────────────────────────────────────────────────────────────────────────────────────────────╮
│  [b] open a browser, [d] open devtools, [l] turn off local mode, [c] clear console, [x] to exit  │
╰──────────────────────────────────────────────────────────────────────────────────────────────────╯
C:\Users\WDAGUtilityAccount\my-first-worker\node_modules\wrangler\wrangler-dist\cli.js:29768
throw a;
^
Error: write EOF
at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:95:16)
at WriteWrap.callbackTrampoline (node:internal/async_hooks:130:17) {
errno: -4095,
code: 'EOF',
syscall: 'write'
}
Node.js v20.18.0
PS C:\Users\WDAGUtilityAccount\my-first-worker>
Please provide a link to a minimal reproduction
No response
Please provide any relevant error logs
C:\Users\WDAGUtilityAccount\my-first-worker\node_modules\wrangler\wrangler-dist\cli.js:29768
throw a;
^
Error: write EOF
at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:95:16)
at WriteWrap.callbackTrampoline (node:internal/async_hooks:130:17) {
errno: -4095,
code: 'EOF',
syscall: 'write'
}
Node.js v20.18.0
PS C:\Users\WDAGUtilityAccount\my-first-worker>

I even have the same issue on WSL.

I’m experiencing the same issue on WSL as well.

hey! can you check if following this comment helps? https://github.com/cloudflare/workers-sdk/issues/3698#issuecomment-2089044668

I'm getting this on Windows 11, node v22.11.0. I am using CMD to run wrangler dev.


Re-factor DefaultExternalServices into a regular class, without static methods

Please refer to the individual commit messages for additional details.

/botio-linux preview

/botio test

Thank you for improving this!


feat: add support for secp256r1 identity in ic_agent.

I created this identity out of necessity to implement access_control_test.
See https://github.com/dfinity-lab/dfinity/pull/8317

This feature is now in master, closing this.