text:
Regression in givens

I actually first found this regression when upgrading from 3.4.0 to 3.4.1-RC1, but during minimization I reached a point where the error always surfaced until I went back to 3.0.0 and saw no error. Aux pattern can be used as a workaround. I bisected it to the versions below.
Compiler version
Last good release: 3.0.2-RC1-bin-20210609-fdbb94f-NIGHTLY
First bad release: 3.0.2-RC1-bin-20210610-fe2fcc4-NIGHTLY
bisect: https://github.com/scala/scala3/commit/ff8659e79351fd8678444eb31ac4b80a915036a5
Minimized code
trait Summon[R, T <: R]:
  type Out
object Summon:
  given [R, T <: R]: Summon[R, T] with
    type Out = R

trait DFTypeAny
trait DFBits[W <: Int] extends DFTypeAny
class DFVal[+T <: DFTypeAny]
type DFValAny = DFVal[DFTypeAny]
type DFValOf[+T <: DFTypeAny] = DFVal[T]
trait Candidate[R]:
  type OutW <: Int
object Candidate:
  type Aux[R, O <: Int] = Candidate[R] { type OutW = O }
  given [W <: Int, R <: DFValOf[DFBits[W]]]: Candidate[R] with
    type OutW = W

extension [L](lhs: L) def foo(using es: Summon[L, lhs.type]): Unit = ???
extension [L <: DFValAny](lhs: L)(using icL: Candidate[L]) def baz: DFValOf[DFBits[icL.OutW]] = ???
extension [L <: DFValAny, W <: Int](lhs: L)(using icL: Candidate.Aux[L, W])
  def bazAux: DFValOf[DFBits[W]] = ???

val x = new DFVal[DFBits[4]]
val works = x.bazAux.foo
val fails = x.baz.foo

Output
26 |val fails = x.baz.foo
   |            ^^^^^^^^^
   |value foo is not a member of DFVal[DFBits[?1.OutW]].
   |An extension method was tried, but could not be fully constructed:
   |
   |    foo[DFVal[DFBits[?1.OutW]]](
   |      baz[DFVal[DFBits[(4 : Int)]]](x)(Candidate.given_Candidate_R[(4 : Int), R])
   |    )(Summon.given_Summon_R_T[R, T])    failed with
   |
   |        no implicit argument of type Summon[DFVal[DFBits[?1.OutW]], (?2 : DFVal[DFBits[?1.OutW]])] was found for parameter es of method foo
   |
   |        where:    ?1 is an unknown value of type Candidate.given_Candidate_R[(4 : Int), DFVal[DFBits[(4 : Int)]]]
   |                  ?2 is an unknown value of type DFVal[DFBits[?1.OutW]]
   |        .
   |        I found:
   |
   |            Summon.given_Summon_R_T[R, T]
   |
   |        But given instance given_Summon_R_T in object Summon does not match type Summon[DFVal[DFBits[?1.OutW]], (?2 : DFVal[DFBits[?1.OutW]])].
   |
   |where:    ?1 is an unknown value of type Candidate.given_Candidate_R[(4 : Int), R]
1 error found

Expectation
No error.

I think that will have to await the improvements in the givens SIP. The second installment should handle tracked parameters. As far as I can see it only worked by accident for this very special case before.

Why is it a special case? It's not like the problem with cascading givens, it's something different.

If you are referring to  #13580, it's not the same thing, IIUC. Notice how the given for candidate is defined. This prevents the given Out loss.

It's simply not supported. The previous wIldcards which were allowed by accident in constraints somehow must have given the illusion that it would work, but they never were meant to solve it, nor can I see how they would be a solution. To support it, we need quite a bit of machinery, all of it implemented in the typeclasses PR. Specifically, we need to track in a class instantiation what are the precise values given as arguments. Look for tracked in the commits and discussions.

If you are referring to https://github.com/scala/scala3/issues/13580, it's not the same thing, IIUC. Notice how the given for candidate is defined. This prevents the given Out loss.

Maybe not. But the symptoms, i.e. a skolem type appearing in the error message and need for the Aux pattern to fix it, looks exactly like what tracked parameters are meant to solve.

Maybe not. But the symptoms, i.e. a skolem type appearing in the error message and need for the Aux pattern to fix it, looks exactly like what tracked parameters are meant to solve.

On a hunch I did the following trick instead of using an Aux pattern:
import compiletime.ops.int.+
extension [L <: DFValAny](lhs: L)(using icL: Candidate[L]) def baz: DFValOf[DFBits[icL.OutW + 0]] = ???

This causes the code to compile successfully.
Those this leads me to believe that this is NOT a type tracking problem, but something else.
(and FWIW, also tried the trick on #13580, and it didn't work)

I am not sure what it is. But the reason it worked before was that it used something that should never happen - wildcards in constraints.

Minimisation:
trait Wrap[W <: Int]

trait IsWrap[R]:
  type OutW <: Int
given [W <: Int, R <: Wrap[W]]: IsWrap[R] with
  type OutW = W

trait Sub[R, T >: R]
given [R, T >: R]: Sub[R, T] with {}

extension [L, W <: Int](lhs: L)(using icL: IsWrap[L]{type OutW = W}) def bazAux: Wrap[W] = ???
extension [L](lhs: L)(using icL: IsWrap[L]) def baz: Wrap[icL.OutW] = ???
extension [L](lhs: L) def foo(using es: Sub[lhs.type, L]): Unit = ???

val x: Wrap[4] = ???
val works = x.bazAux.foo
val alsoWorks =
  val b = x.baz
  b.foo
val fails = x.baz.foo

This is the same issue as in #20053 in the case where only the third alternative is considered.
But still a separate issue than the one with overload resolution.

This also looks like the same issue as #13580 to me, it compiles by replacing the given ... with by
given [W <: Int, R <: DFValOf[DFBits[W]]]: Candidate[R] {type OutW = W} = ???

It seems adding compiletime.ops.int.+ 0 somehow allows the wildcards to get into constraints again.

authors: EugeneFlesselle odersky soronpo


text:
Meticulously document semanticdb.proto

https://github.com/scalameta/scalameta/blob/master/langmeta/semanticdb/shared/src/main/protobuf/semanticdb.proto is currently uncommented. Yet we advertise it as "simple and approachable". We should meticulously document every single field on every message with clear explanations and examples.

Resolved with SemanticDB v3.

source: gharchive/issue

authors: olafurpg xeno-by

repo: scalameta/scalameta

license_type: permissive

license_source: bigquery


text:
Parsing fails on SIP-64 changes

SIP-64 changes context bound and given clause syntaxes. It has been committed to Scala 3 codebase by the commit 14acdc0.
trait Display[A]:
  def display(value: A): String

final case class Cat(name: String, age: Int, color: String)

 given catDisplay: Display[Cat]:
    def display(cat: Cat): String =
      s"${cat.name} is a ${cat.age} year-old ${cat.color} cat."

Note the given definition ends with :, not with, as the latter has been deprecated and emits a warning:

Given member definitions starting with with are no longer supported; use {...} or : followed by newline instead

Using scalafmt 3.8.3 (even the latest v3.8.4-RC3), this fails.
[6] error: /path/to/Cat.scala: org.scalafmt.dynamic.exceptions.PositionExceptionImpl: /path/to/Cat.scala:6: error: [dialect scala3] `;` expected but `:` found
[6]   given catDisplay: Display[Cat]:
[6]                                 ^
[6] Caused by: /path/to/Cat.scala:6: error: [dialect scala3] `;` expected but `:` found
[6]   given catDisplay: Display[Cat]:
[6]                                 ^
[6] 	at org.scalafmt.Scalafmt$.$anonfun$doFormatOne$2(Scalafmt.scala:111)
[6] 	at scala.meta.parsers.Parsed.fold(Errors.scala:12)
[6] 	at scala.meta.parsers.Parsed.fold$(Errors.scala:10)
[6] 	at scala.meta.parsers.Parsed$Error.fold(Errors.scala:28)
[6] 	at org.scalafmt.Scalafmt$.doFormatOne(Scalafmt.scala:114)
[6] 	at org.scalafmt.Scalafmt$.doFormat(Scalafmt.scala:90)
[6] 	at org.scalafmt.Scalafmt$.$anonfun$formatCode$3(Scalafmt.scala:78)

duplicate of #4047.

authors: asarkar kitbellew


text:
Setting a random seed

Hello!
I have a feature request, and would be happy to put up a PR if I receive positive feedback for it.
Currently, as far as I understand, it is a bit complicated to set a specific random seed for a probability distribution.  For instance:
import breeze.stats.distributions.{Uniform,RandBasis,ThreadLocalRandomGenerator}
import org.apache.commons.math3.random.{MersenneTwister}

def setSeed(seed: Int = 0) = {
      new RandBasis(new ThreadLocalRandomGenerator(new MersenneTwister(seed)))
}

val dist = new Uniform(0, 1)(setSeed())

I know that RandBasis.mt0 exists, but the actual seed value is an AtomicInteger, and not a configurable value.
val dist = new Uniform(0, 1)(RandBasis.mt0)

I would like to make it easier to configure the seed for Breeze distributions, and I propose defining the setSeed function above as a method on the RandBasis object, so we'd have RandBasis.setSeed(seed: Int) as an option in addition to RandBasis.mt0.
I have 3 questions:

Is this a good idea?
Are there better ways or other ways to set a random seed?
Does it make sense for me to open a PR to add the RandBasis.setSeed method?

Thank you!

Yeah, this is great, except:

I'd probably say "withSeed" or "seeded" or something instead of setSeed,
since it's not actually a setter.
The atomic integer is important because with your code every thread gets
its own random generator with the same seed.

I'd happily accept a PR with those changes.
-- David
On Thu, Feb 4, 2016 at 10:48 AM, Alex Gaudio notifications@github.com
wrote:

Hello!
I have a feature request, and would be happy to put up a PR if I receive
positive feedback for it.
Currently, as far as I understand, it is a bit complicated to set a
specific random seed for a probability distribution. For instance:
import breeze.stats.distributions.{Uniform,RandBasis,ThreadLocalRandomGenerator}
import org.apache.commons.math3.random.{MersenneTwister}
def setSeed(seed: Int = 0) = {
new RandBasis(new ThreadLocalRandomGenerator(new MersenneTwister(seed)))
}
val dist = new Uniform(0, 1)(setSeed())
I know that RandBasis.mt0 exists, but the actual seed value is an
AtomicInteger, and not a configurable value.
val dist = new Uniform(0, 1)(RandBasis.mt0)
I would like to make it easier to configure the seed for Breeze
distributions, and I propose defining the setSeed function above as a
method on the RandBasis object, so we'd have RandBasis.setSeed(seed: Int)
as an option in addition to RandBasis.mt0.
I have 3 questions:

Is this a good idea?
Are there better ways or other ways to set a random seed?
Does it make sense for me to open a PR to add the RandBasis.setSeed
method?

Thank you!
—
Reply to this email directly or view it on GitHub
https://github.com/scalanlp/breeze/issues/492.

authors: adgaudio dlwh

repo: scalanlp/breeze


text:
Please enable CONFIG_KEXEC

Hi!
Given that there is no RancherOS image (although there is a 4.5.4-rancher kernel that is not directly available), I tried to boot RancherOS though kexec, but std kernel does not have CONFIG_KEXEC enabled and 4.5.4-coreos kernel (which has it) is not compatible with Ubuntu/Alpine images (no network).
Would you please enable this flag? Being able to use RancherOS on your platform would be awesome.
Thanks!

Wow! You are quick! :)

Waiting for #273 to be fixed before releasing a new kernel

RancherOS works prefectly when installed on a secondary disk (VC1M and VC1L) and booted through KEXEC.

authors: albertdb moul

repo: scaleway/kernel-tools

license: mit


text:
fix(typings): correct generated types + some tests

Summary
Global types were not being injected in built declaration file

.ts is better than .d.ts for type declaration ? @chambo-e

source: gharchive/pull-request

authors: DorianMaliszewski chambo-e

repo: scaleway/scaleway-ui

license_source: github-api


text:
refactor(ci): use official scw action

Summary
What's changed?
This PR removes the custom action and replaces it with the new official Scaleway action.
Why do we need this?
It's much cleaner and the new action introduces some parameter validation
How have you tested it?
Not tested, will need to push a new build
Checklist

[x] I have reviewed this myself
[ ] There is a unit test covering every change in this PR
[ ] I have updated the relevant documentation
[ ] I have upgraded the VERSION file to push the gateway image with a new tag

Details

Shouldn't be merged until save_config is added to the action

repo: scaleway/serverless-gateway

license: MIT


text:
NoMethodError Exception: undefined method `primary_key'

I did this in rails console
current_user.invite!(email: 'cool2@gmail.com')
somehow i kept getting

*** NoMethodError Exception: undefined method `primary_key' for Hash:Class

Any idea guys?

Hey guys i got it working
it suppose to be like this actually, my brain is not working correctly.
User.invite!({email: "cool1@gmail.com"}, current_user)


text:
Intermittent AttributeError during Association

Traceback (most recent call last):
  File "/opt/python/3.3.5/lib/python3.3/threading.py", line 901, in _bootstrap_inner
    self.run()
  File "./pynetdicom3/DULprovider.py", line 487, in run
    if self.CheckNetwork():
  File "./pynetdicom3/DULprovider.py", line 387, in CheckNetwork
    return self.is_transport_connection_event()
  File "./pynetdicom3/DULprovider.py", line 456, in is_transport_connection_event
    self.CheckIncomingPDU()
  File "./pynetdicom3/DULprovider.py", line 329, in CheckIncomingPDU
    self.pdu = Socket2PDU(bytestream, self)
  File "./pynetdicom3/DULprovider.py", line 582, in Socket2PDU
    acse = dul.association.acse
AttributeError: 'Association' object has no attribute 'acse'

I've only seen it during Travis builds, weirdly.

Seems to occur due to the DUL being created and started before Association.acse is set, but DUL.Socket2PDU shouldn't be called unless there's network activity on the socket.


text:
audit: wrong credentials appears in clear

administrator has the ability to view the access logs of users.
If a user fails an authentication, credentials are registered and can be viewed in clear.

Identity providers have a configurable level of audit:

minimal: only error information
details: add exception and web details
full: add full messages

Configure a level of DETAILS or MINIMAL to avoid storing requests with username+credentials in audit events.
Related #104

authors: gianpaolo-tndigit matteo-s

repo: scc-digitalhub/AAC


text:
Look into implementing dynamic/computed styles (for category colors, etc)

It seems there are many options, whole section just on React-style styling here:
https://survivejs.com/react/advanced-techniques/styling-react/

I haven't been able to find a clear winner in the React Style War, and seems like a lot of the paradigms are pretty radical/different/specific...
@sccottt how would you feel about sticking with what we have now: a separate set of SCSS->CSS styles that apply to the whole page, a la traditional web dev?
And then we could slip in a certain amount of computed properties per-component. Like with Category Colors, we could calculate those in JS and apply them to individual elements during render()

Like inline styles? I'm down w/ that

Yeah inline styles where we need em

FWIW it sounds like the two current community-embraced solutions are:

https://github.com/styled-components/styled-components
https://github.com/css-modules/css-modules

authors: alexburner sccottt

repo: sccottt/endeavors


text:
fix: Do not re-raise InvalidArgument exception as InvalidSchema in non-Schemathesis tests

Resolves #1514

Codecov Report

Merging #1520 (fef2789) into master (f2261ab) will decrease coverage by 0.13%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1520      +/-   ##
==========================================
- Coverage   99.04%   98.90%   -0.14%
==========================================
  Files          91       91
  Lines        7014     6956      -58
  Branches     1203     1203
==========================================
- Hits         6947     6880      -67
- Misses         40       45       +5
- Partials       27       31       +4

Impacted Files
Coverage Δ

src/schemathesis/extra/pytest_plugin.py
95.58% <100.00%> (-2.95%)
:arrow_down:

...c/schemathesis/specs/openapi/negative/mutations.py
97.92% <0.00%> (-1.67%)
:arrow_down:

src/schemathesis/specs/openapi/loaders.py
98.31% <0.00%> (-0.85%)
:arrow_down:

src/schemathesis/serializers.py
98.18% <0.00%> (-0.11%)
:arrow_down:

src/schemathesis/runner/serialization.py
97.91% <0.00%> (-0.11%)
:arrow_down:

...rc/schemathesis/specs/openapi/negative/__init__.py
95.91% <0.00%> (-0.09%)
:arrow_down:

src/schemathesis/lazy.py
91.25% <0.00%> (-0.06%)
:arrow_down:

src/schemathesis/runner/impl/core.py
97.83% <0.00%> (-0.02%)
:arrow_down:

src/schemathesis/models.py
99.08% <0.00%> (-0.02%)
:arrow_down:

... and 16 more

Continue to review full report at Codecov.

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

repo: schemathesis/schemathesis


text:
How to directly access pdf stream instead of writing file

I have a question. I need to generate bills and send them per email. I dont want to save the files on my server.
With nodemailer and pdfkit i can achieve this like this:
const doc = new pdfkit();

transport.sendMail({
  from: '...',
  to: '...',
  subject: '...',
  text: '...',
  attachments: [{
    filename: 'attachment.pdf',
    content: doc,
  }],
});

A pdfkit instance is a stream, and can simply be passed to nodemailer.
With a qrbill instance this does not work, even though it extends from pdfkit. (which extends from stream). I did a workaround and achieved this like so:
const dummyStream = new Writable({
    write(chunk, controller) {},
  })
const doc = new PDF(billData, dummyStream, {autoGenerate: false, size: 'A4'})

// create invoice pdf
doc.end()

transport.sendMail({
  from: '...',
  to: '...',
  subject: '...',
  text: '...',
  attachments: [{
    filename: 'attachment.pdf',
    content: await buffer(doc),
  }],
});

I just wonder if there is an easier/better way?

Thank you for creating this issue. I wasn't aware of this. So no, there is currently no other way of doing this. But I am working on a refactoring of this module and I will keep this in mind.

With SwissQRBill v4 this is now possible.
Example:

const data = {
  amount: 1994.75,
  creditor: {
    account: "CH44 3199 9123 0008 8901 2",
    address: "Musterstrasse",
    buildingNumber: 7,
    city: "Musterstadt",
    country: "CH",
    name: "SwissQRBill",
    zip: 1234
  },
  currency: "CHF",
  debtor: {
    address: "Musterstrasse",
    buildingNumber: 1,
    city: "Musterstadt",
    country: "CH",
    name: "Peter Muster",
    zip: 1234
  },
  reference: "21 00000 00003 13947 14300 09017"
};

const pdf = new PDFDocument();
const qrBill = new SwissQRBill(data);

qrBill.attachTo(pdf);
pdf.end();

transport.sendMail({
  attachments: [{
    content: await buffer(pdf),
    filename: "attachment.pdf"
  }],
  from: "...",
  subject: "...",
  text: "...",
  to: "..."
});

authors: fionues schoero

repo: schoero/swissqrbill


text:
Example "scholarly.search_pubs" not working expectedly

Tried the search_pubs sample code, but it doesn't work expectedly
from fp.fp import FreeProxy
from scholarly import scholarly
proxy = FreeProxy(rand=True, timeout=1, country_id=['US', 'CA']).get()
scholarly.use_proxy(http=proxy, https=proxy)
search_query = scholarly.search_pubs('Perception of physical stability and center of mass of 3D objects')
print(next(search_query))
Exception: Cannot fetch the page from Google Scholar.

You need to catch the exception and try again. I updated the example code in the README.

repo: scholarly-python-package/scholarly

license: Unlicense


text:
Custom mapper for UnmodifiableListView Type

Hi, I'm tryng to change some class properties from type List to UnmodifiableListView, so facing some errors in the mappers, what should be the correct way to setup a CustomMapper for this type UnmodifiableListView that is from the dart:collection package.
I already tried with SimpleMapper1 or a MappingHook but I coudn't create one that didn't throw an error Failed to decode ...
// user_modifiable.dart file, works out of the box
import 'package:dart_mappable/dart_mappable.dart';

part 'user_modifiable.mapper.dart';

@MappableClass()
class UserModifiable with UserModifiableMappable{
  const UserModifiable({
    required this.userLogs,
    required this.userDeviceIds,
  });
  final List<String> userLogs;
  final List<int> userDeviceIds;
}

// user_unmodifiable.dart file, need a CustomMapper to recognize the UnmodifiableListView type
import 'dart:collection' show UnmodifiableListView;

import 'package:dart_mappable/dart_mappable.dart';

part 'user_unmodifiable.mapper.dart';

@MappableClass()
class UserUnmodifiable with UserUnmodifiableMappable{
  const UserUnmodifiable({
      required this.userLogs,
      required this.userDeviceIds,
  });
  final UnmodifiableListView<String> userLogs;
  final UnmodifiableListView<int> userDeviceIds;
}

CustomMapper/SimpleMapper is the right choice here.
Can you also post the code using that then I can check where the problem is.

I ended up finding out with the FIC example, not sure which option is the best performing
void main() {
  MapperContainer.globals.use(
    UnmodifiableListViewMapper(),
  );
}

class UnmodifiableListViewMapper
    extends SimpleMapper1<UnmodifiableListView<dynamic>> {
  @override
  UnmodifiableListView<T> decode<T>(dynamic value) {
    return UnmodifiableListView<T>(
      (value as Iterable).map((e) => MapperContainer.globals.fromValue<T>(e)),
    );
  }

  @override
  dynamic encode<T>(UnmodifiableListView<T> self) {
    return self
        .map((item) => MapperContainer.globals.toValue<T>(item))
        .toList();
  }

  @override
  // ignore: avoid_dynamic_calls
  Function get typeFactory => <T>(Function f) => f<UnmodifiableListView<T>>();
}

Or just this:
void main(){
  MapperContainer.globals.useAll([
      SerializableMapper<UnmodifiableListView<dynamic>, Object>.arg1(
        decode: <T>(json, fromJsonT) =>
            UnmodifiableListView<T>((json as Iterable).map(fromJsonT)),
        encode: (UnmodifiableListView<dynamic> value) =>
            (Object? Function(dynamic) toJsonT) => value.map(toJsonT).toList(),
        type: <E>(f) => f<UnmodifiableListView<E>>(),
      ),
    ]);
}

I would go with the first one.
Also you might want to add with MapperEqualityMixin< UnmodifiableListView> and implement the equality method to enable equal and hashCode on this type.

Closing this as I think this solves the issue. If not you can reopen.

authors: hectorAguero schultek


text:
[Feature]: Allow Formatting Components using the Spread Operator ..

When attempting to format this page, it complained about the spread operator:
error: expected an expression
   ┌─ /home/mahmoud/portfolio/wiseai.dev/src/pages/landing.rs:21:30
   │
21 │       <Hero ..profile_props />
   │                              ^

So, I would like to suggest enabling the formatting of components using the spread operator. Thanks!
Edit: In some cases, it works as expected, like in this line of code, probably because it is wrapped with {}.

Thank you for reporting this, should be fixed in v0.3.0, feel free to reopen this issue if the problem resurfaces


text:
Clarify how behaviours trees work in 3.2

Started on this but not sure if it's better to prune section and leave details to people interested in reading the source code.

Rewrote how behaviour nodes communicates to make it more clear.


text:
Altera a largura do ícone "Acesso Aberto"

O que esse PR faz?
altera a largura do icone oa que fica localizado no footer da aplicação
Onde a revisão poderia começar?
style.css
Como este poderia ser testado manualmente?
Acesse o sistema com o firefox e verifique se o ícone oa está corretamente exibido.
Em outra versão o ícone parecia mais quadrado. Com a largura maioir. Agora foi corrigido.
Algum cenário de contexto que queira dar?
Apenas verifique no footer. O ícone estará alinhado e em suas dimensões corretas.
Screenshots
antes do ajuste (firefox):

depois (firefox

Quais são tickets relevantes?
#95
Referências
apenas reduzi a largura.

@joffilyfe foi alterado um arquivo .sass que não enviamos.
O arquivo sass é processa do gera o arquivo minificado.
Caso seja necessário, posso enviar o arquivo sass para melhor entendimento do ajuste.

@joffilyfe foi alterado um arquivo .sass que não enviamos.
O arquivo sass é processado e gera o arquivo minificado.
Caso seja necessário, posso enviar o arquivo sass para melhor entendimento do ajuste.

@paratiuid tudo bem, obrigado pela explicação. Nós gostaríamos que os arquivos fonte fossem enviados e não mais o resultado da conversão.
Não é necessário que o resultado seja versionado no repositório mas é necessário que todos os fontes utilizados estejam sim versionados. Em breve mudaremos o dockerfile para que a conversão dos assets seja feita durante o build da imagem.

@joffilyfe
vou enviar os arquivos sass então.

@joffilyfe
no arquivo style.scss na linha 911 existe a classe .ico-oa.
Apenas foi alterada a propriedade background-size.
Como estava antes do ajuste:

Como ficou após o ajuste:

@paratiuid Obrigado pelos arquivos scss. Sobre o seu PR eu tenho uma dúvida:

O background-size utilizado possui uma dimensão fixa e até achatada, porque vocês não utilizaram algo como 10% ou background-size: contain?

Uma outra coisa que acabei observando é que o paragrafo possui uma margem inferior padrão e que o desloca para cima. O que vocês acham de zerar o margin do p interno ao ico-oa. Fiz um testes local e obtive o seguinte resultado:

Além dos comentários do @joffilyfe, importante também manter o padrão do site SciELO Brasil (Coleção), onde esse ícone também aparece.

@joffilyfe @alexxxmendonca
efetuei os ajustes conforme solicitados.

@paratiuid, vocês poderiam, por gentileza, resolver os conflitos?

@paratiuid estamos trabalhando para adicionar a mimificação de css e js no Docker, após essa atividade peço que seja enviado uma alteração nesse PR com os arquivo não mimificados.

@cesarbruschetta @jamilatta @joffilyfe
acabo de resolver os conflitos.

@cesarbruschetta  por gentileza você pode verificar o merge novamente?

Testado e aprovado em homologação.

authors: alexxxmendonca gustavofonseca jamilatta joffilyfe paratiuid


text:
Botões de compartilhamento quebram layout

Em alguns casos, os botões de compartilhamento ultrapassam os limites estabelecidos do layout:

http://search.scielo.org/?fb=&q=*&where=&filter[year_cluster][]=0016&filter[year_cluster][]=0015

Testado e aprovado em http://homolog.search.scielo.org/

repo: scieloorg/search-journals


text:
Metal rendering in mixed immersion now supported in VisonOS 2

https://developer.apple.com/wwdc24/10092
It sounds like depth rendering would need to be properly implemented first.
https://github.com/scier/MetalSplatter/issues/12

I was so happy about that. This has absolutely moved to the top of my TODO list for MetalSplatter :-)

repo: scier/MetalSplatter


text:
Weights normalization in ReweightDensity

Hi everyone,
I wonder why the weight are normalized in ReweightDensity cf https://github.com/scikit-adaptation/skada/blob/9e7905ddbbc2823eb3f48cb08e6cd5278bd2385a/skada/_reweight.py#L108 ?
After some tests, I observed that the strange behavior of ReweightDensity in the comparison example is due to the weight normalization. cf. https://scikit-adaptation.github.io/auto_examples/plot_method_comparison.html#sphx-glr-auto-examples-plot-method-comparison-py
Maybe, we should remove the normalization or at least divide by the mean instead of the sum (dividing by the sum provokes a dependance of the weights with respect to the dataset size, which should be avoided, I think).

You are right, when comparing the weights obtained with this methods, with those from the others, it is the only one that is normalized in such a way (all other reweighting methods have some weights bigger than 1), so it might be better not to normalize it

From the code, it seems like normalization here is specifically to produce density. Right? DiscriminatorReweightDensityAdapter also returns density (normalized), it just does so by calling predict_proba on the classifier.

maybe it is a mistake, and we shouldn't give a density in both cases:
those are the two worst performing reweighting method, being worst on the example than when we are not using da
(see: https://output.circle-artifacts.com/output/job/8955b99a-a58c-4b5c-afb0-8bcb4c545245/artifacts/0/dev/auto_examples/plot_reweighting.html#sphx-glr-auto-examples-plot-reweighting-py )
also I think weights are not supposed to be density, those are just supposed to be the quotient of two probabilities, and thus can be highter than 1, and have a sum highter than 1

I agree with you that this reweighting  with just probabilities is not correct or the one from the papers (I would cite the review of sugiyama instead of GAn though ;)). OK for weights that sum to n instead of 1 because indeed it changes the proper parameters (C or alpha) in the sklearn models. I juts had the problem when implementing the JDOT classifier.

Also about the Reweight adapter we should maybe rename them without density everywhere; density is used in the model that use a density estimator, but it would make sens to remove teh desnsity for the Gaussian one (it is implied in  a way) and the discriminator one. We did not use density for KMM either. As log as Reweight is in the same it is enough I think.

Ok thank you @rflamary,
I will open a PR to correct these few issues

closing this usse fixed in #118

authors: BuenoRuben antoinedemathelin kachayev rflamary

repo: scikit-adaptation/skada


text:
fixed the two time correlation notebook

Changed the two time correlation notebook after changing the results shape in the skbeam/core/correlation.py  to have (num_rois, len(lag_steps), len(lag_steps))

@sameera2004 Looks really good. Thanks for your effort on this.  Two comments

Can you plot the results from correlating the first half?
The formatting in cell [10] is a little off, can you fix that?

@ericdill I added  a plot to show the results from first half data set and fixed the PR, ready to review

Thanks!

@ericdill  Thanks

repo: scikit-beam/scikit-beam-examples


text:
Fix TabularMSALoc slicing on Python 3.12 and change documentation for skbio.io.format.stockholm to be independent of OrderedDict repr

Since slice objects are hashable in Python 3.12, pd.MultiIndex no longer raises a TypeError when its __contains__ method is called with a slice object. Instead, Pandas checks whether the argument is a slice and raises an InvalidIndexError instead. This change catches such errors in addition to TypeError to fix slicing for TabularMSALoc.
Python 3.12 also changes the repr for OrderedDict. This change revises the docstring for skbio.io.format.stockholm to display OrderedDict objects as lists of items so that we get the same results on Python 3.12 as we do on earlier versions of Python.
fixes #1926

Please complete the following checklist:

[x] I have read the guidelines in CONTRIBUTING.md.

[x] I have documented all public-facing changes in CHANGELOG.md.

[ ] This pull request includes code, documentation, or other content derived from external source(s). If this is the case, ensure the external source's license is compatible with scikit-bio's license. Include the license in the licenses directory and add a comment in the code giving proper attribution. Ensure any other requirements set forth by the license and/or author are satisfied. It is your responsibility to disclose code, documentation, or other content derived from external source(s). If you have questions about whether something can be included in the project or how to give proper attribution, include those questions in your pull request and a reviewer will assist you.

[x] This pull request does not include code, documentation, or other content derived from external source(s).

Note: REVIEWING.md may also be helpful to see some of the things code reviewers will be verifying when reviewing your pull request.

@actapia Thanks a lot!

authors: actapia qiyunzhu

repo: scikit-bio/scikit-bio


text:
Implemented Accuracy Weighted Ensemble

Implementation of Accuracy Weighted Ensemble
Changes proposed in this pull request:

Implementation of Accuracy Weighted Ensemble
Documentation complies to the format of reStructuredText

@scikit-multiflow/scikit-multiflow-repo-admins
Checklist

[x] Code complies with PEP-8 and is consistent with the framework.
[x] Code is properly documented.
[x] Tests are included for new functionality.
[x] Travis CI build passes.
[x] Test Coverage is maintained (threshold 0.2%)

Thanks @MinhHuong!
I will merge the PR.

authors: MinhHuong jacobmontiel

repo: scikit-multiflow/scikit-multiflow


text:
AttributeError: 'module' object has no attribute 'UMFPACK_INFO'

Travis has been recently failing on us (project Florence) with a scikit-umfpack error on python 2.7 under Ubuntu 14.04. UMFPack is installed using the usual (libsuitesparse-dev) protocol. Here is the short version of the error log:
ERROR: test.test_examples
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/virtualenv/python2.7.14/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/home/travis/build/romeric/florence/tests/test.py", line 199, in test_examples
    simple_laplace(optimise=False, recompute_sparsity_pattern=True, squeeze_sparsity_pattern=False)
  File "../examples/simple_laplace/simple_laplace.py", line 45, in simple_laplace
    mesh=mesh)
  File "/home/travis/build/romeric/florence/Florence/Solver/FEMSolver.py", line 498, in Solve
    formulation, mesh, function_spaces, solver, contact_formulation=contact_formulation)
  File "/home/travis/build/romeric/florence/Florence/Solver/FEMSolver.py", line 215, in __checkdata__
    solver = LinearSolver(linear_solver="direct", linear_solver_type="umfpack", geometric_discretisation=mesh.element_type)
  File "/home/travis/build/romeric/florence/Florence/Solver/Solver.py", line 75, in __init__
    from scikits.umfpack import spsolve
  File "/home/travis/virtualenv/python2.7.14/lib/python2.7/site-packages/scikits/umfpack/__init__.py", line 12, in <module>
    from .umfpack import *
  File "/home/travis/virtualenv/python2.7.14/lib/python2.7/site-packages/scikits/umfpack/umfpack.py", line 130, in <module>
    from . import _umfpack as _um
  File "/home/travis/virtualenv/python2.7.14/lib/python2.7/site-packages/scikits/umfpack/_umfpack.py", line 98, in <module>
    UMFPACK_INFO = __umfpack.UMFPACK_INFO
AttributeError: 'module' object has no attribute 'UMFPACK_INFO'

The full travis log can be found here. The problem is very recent and did not exist maybe a couple of weeks ago. The issue does not appear under python 3.5/3.6/3.7. Has anything changed in the recent release (0.3.2)?

No, 0.3.2 contains only some minor modifications w.r.t. 0.3.1. Could you try forcing the 0.3.1 version in your travis setup?

Forcing travis to 0.3.1 version does actually solve the problem. Log here.

OK. So I suspect that the 0.3.2 manylinux wheels that pip installs might be wrong, see also https://github.com/scikit-umfpack/scikit-umfpack-wheels/issues/2. I will try to investigate, but I am not very good in solving CI issues, so for the moment, you can either pip install the 0.3.1, or build 0.3.2 from sources.

authors: rc romeric

repo: scikit-umfpack/scikit-umfpack


text:
Unexpected behaviour in normaltest (bug?)

Hi all,
I get an unexpected behaviour when running normaltest.
In order to check it working I generate a normal distribution and I apply normaltest. What I see is distinct normaltest result for every new normal distribution.
Shapiro test, very similar test to check normality, indeed gives high p values.
I understand that pvalues higher than 0.05 reject the null hypotesis that the test distribution is different by a normal distribution, but I was not expecting that with the same distribution I get so high volatility of p values.
how is possible that normaltest gives different results (and low p-values) for normal distributions?
I am on v. 1.1.0
Best

Reproducing code example:
import scipy.stats as stats
import numpy as np
[stats.normaltest(np.random.normal(0, 1, 10**6)) for i in range(10)]
[stats.shapiro(np.random.normal(0, 1, 10**6)) for i in range(10)]
Scipy/Numpy/Python version information:

This is expected. P value should be uniformly distributed between 0 and 1 and it is

authors: giocolangelo sethtroisi

repo: scipy/scipy


text:
scipy.optimize.curve_fit fails with xdata that can't be converted to float, against docs

The scipy curve_fit documentation says that xdata can be an object:

xdataarray_like or object
The independent variable where the data is measured. Should usually be an M-length sequence or an (k,M)-shaped array for functions with k predictors, but can actually be any object.

(emphasis mine)
This is currently not respected. Previously, anything could be passed in, but with 1.2.3, it appears that a numpy array is assumed and xdata is modified to float64.
xdata = xdata.astype(float)
The xdata should not be modified by curve_fit since it's not, in any way, meant for curve_fit to consume. It's meant for our models. These may rely on the data types of the xdata, possibly non-numeric. Even for numeric models, casting to float breaks models that rely on the data types passed to them, or would require possibly lossy conversions back.
This is a regression that breaks all models that use something besides float64 numpy arrays or need to preserve data types for their models to work.
Reproducing code example:
from scipy.optimize import curve_fit

class ExampleObject(object):
    def __init__(self, a=5, b=3.0):
        self.a = 5.0
        self.b = 3.0

def model(xdata, k):
    return xdata.a * k

values = range(10)

answer = curve_fit(
            model,  # Function to fit the data to
            xdata=ExampleObject(),
            ydata=values,
            p0=[1.0],
        )

Error message:
  File "/usr/local/lib/python2.7/site-packages/scipy/optimize/minpack.py", line 716, in curve_fit
    xdata = xdata.astype(float)
AttributeError: 'ExampleObject' object has no attribute 'astype'

Scipy/Numpy/Python version information:
('1.2.3', '1.16.6', sys.version_info(major=2, minor=7, micro=17, releaselevel='final', serial=0))

This is a no-repro on 1.4 and current master. So apparently it is fixed already.
In[2]: answer
Out[2]: (array([0.9]), array([[0.03666667]]))

Duplicate of #10196

A quacking workaround for anyone hitting this in 1.2.3:
class XdataWorkaround(object):
    """ Temporary workaround for scipy==1.2.3 (): https://github.com/scipy/scipy/issues/11662 """
    def __init__(self, xdata):
        if scipy.__version__ != "1.2.3":
            raise Exception("Remove this workaround. Only applicable for scipy 1.2.3")
        self.xdata = xdata

    def astype(self, t):
        """ When curve_fit calls xdata.astype(float), return the original xdata.  """
        return self.xdata

Example usage:
answer = curve_fit(
            model,  # Function to fit the data to
            xdata= XdataWorkaround(my_xdata),
            ydata=values,
            p0=[1.0],
        )

authors: brandonrwin ilayn


text:
Uninformative error message from bisplev function

Code: see the post https://stackoverflow.com/questions/46983476/
Got error message:

The error message Invalid input data is uninformative.
Is it possible to provide the reason or solution of the error in the error message?

I think this is duplicate with #8565. The error message should be improved, I think.

Fixed by gh-13436, so closing.

authors: AtsushiSakai ZhihuiChen0903 ev-br


text:
BUG: barycentric_interpolate gives incorrect result

Describe your issue.
The following function in scipy seems to have a bug. The interpolation is simple and should be between 1.2577 or so, but the solution it provides is 4105.142857162852. This is magnitudes higher than it should.
Reproducing Code Example
y = [1.3054064754226626, 1.3051442503342239, 1.3046461717838198, 1.303961061883361, 1.3031520786211213, 1.302288522779524, 1.3014401106634819, 1.3006720983836826, 1.3000413996420381, 1.29959401552044, 1.299362191731675, 1.2992427174944052, 1.2990120737813193, 1.2985714718258516, 1.297960059617664, 1.297230432357875, 1.2964437217487188, 1.2956640744943522, 1.29495346818699, 1.2943671338786111, 1.2939497540972333, 1.2937329889665372, 1.2936211702931346, 1.2934051113756502, 1.2929916979262934, 1.2924166745392112, 1.2917286648486574, 1.290984912741464, 1.2902461438207935, 1.289571516863928, 1.2889877654677373, 1.288589420111797, 1.2883824052603141, 1.2882755816000133, 1.2880691092755212, 1.2876738102440777, 1.2871235150883948, 1.2864644426246792, 1.2857512636231114, 1.285042223635671, 1.2843942588910426, 1.2838585232597615, 1.2834766198913865, 1.2832781137241156, 1.283175671582022, 1.2829776510527147, 1.2825984740676093, 1.282070502857373, 1.2814380028840044, 1.2807533998111436, 1.280072608632269, 1.279450334953143, 1.2789357599892566, 1.278568900255119, 1.27837820080912, 1.2782797841717004, 1.278089538780742, 1.2777253474561543, 1.27721791144859, 1.2766100909045373, 1.2759521277607397, 1.2752977600633868, 1.274699584350805, 1.2742049005461726, 1.2738522032915072, 1.273668859867505, 1.273574238020874, 1.2733913253141604, 1.2730410460074677, 1.2725532472153502, 1.2719687801672708, 1.271336061877815, 1.2707067677138126, 1.2701314856724393, 1.2696557168197267, 1.269316496238796, 1.2691401555382982, 1.2690491469829905, 1.2688732176849062, 1.2685363066136401, 1.2680671139154125, 1.2675049252025354, 1.2668963076592663, 1.266290968207135, 1.2657375726665283, 1.2652797891825778, 1.2649535719069105, 1.264783933875138, 1.2646963842259353, 1.2645271407913103, 1.2642030313904762, 1.263751662672223, 1.2632108253385246, 1.2626253169850759, 1.2620429577880883, 1.2615105677169316, 1.261070262341188, 1.2607563227576066, 1.2605931229080263, 1.2605088959735316, 1.260346075720066, 1.2600342670871711, 1.2596000293730265, 1.259079719941599, 1.2585164374378117, 1.2574441394892257, 1.257020683951854, 1.256718784164943, 1.2565618511234287]
x = [0.00405, 0.01992, 0.05039, 0.09298, 0.14423, 0.2, 0.25577, 0.30702, 0.34961, 0.38008, 0.39595, 0.40415, 0.42002, 0.45048, 0.49305, 0.54429, 0.60005, 0.65581, 0.70705, 0.74962, 0.78008, 0.79595, 0.80415, 0.82002, 0.85048, 0.89305, 0.94429, 1.00005, 1.05581, 1.10705, 1.14962, 1.18008, 1.19595, 1.20415, 1.22002, 1.25048, 1.29305, 1.34429, 1.40005, 1.45581, 1.50705, 1.54962, 1.58008, 1.59595, 1.60415, 1.62002, 1.65048, 1.69305, 1.74429, 1.80005, 1.85581, 1.90705, 1.94962, 1.98008, 1.99595, 2.00415, 2.02002, 2.05047, 2.09305, 2.14429, 2.20005, 2.25581, 2.30705, 2.34962, 2.38008, 2.39595, 2.40415, 2.42002, 2.45048, 2.49305, 2.54429, 2.60005, 2.65581, 2.70705, 2.74962, 2.78008, 2.79595, 2.80415, 2.82002, 2.85048, 2.89305, 2.94429, 3.00005, 3.05581, 3.10705, 3.14963, 3.18008, 3.19595, 3.20415, 3.22002, 3.25048, 3.29305, 3.34429, 3.40005, 3.45581, 3.50705, 3.54962, 3.58008, 3.59595, 3.60415, 3.62002, 3.65048, 3.69305, 3.74429, 3.80005, 3.90705, 3.94962, 3.98008, 3.99595]

sol = 1.2577179114
x_eval = 3.85581

y_eval = interpolate.barycentric_interpolate(x, y, x_eval)

Error message
None

SciPy/NumPy/Python version information
1.7.1 1.19.0 sys.version_info(major=3, minor=9, micro=7, releaselevel='final', serial=0)

Are you sure that the specific algorithm used by barycentric_interpolate ought to produce such a number? For example, do you have another implementation of barycentric interpolation in another software that produces the number that you want?
Please note the docstring warns that barycentric interpolation, like most polynomial interpolators, is susceptible to Runge's phenomenon if you do not select the sample points very carefully. I suspect that is what is happening here.

Consider using Akima1DInterpolator, CubicSpline, or PchipInterpolator (assuming the data remains monotonic). These are piecewise interpolators that do not have the same problems fitting a high-degree polynomial to all of the points.

No activity since 2021, observed behavior is explained, recommended alternatives should indeed be more appropriate. Closing, thanks all.

authors: ev-br gfranco008 rkern


text:
It's not that obvious that firls requires an even number of edges

Hi!
This line requires the length of bands to be even:
https://github.com/scipy/scipy/blob/b5d8bab88af61d61de09641243848df63380a67f/scipy/signal/_fir_filter_design.py#L982
But from the docs, and the example that uses a flattened sequence as bands (see below), it's not that obvious that firls requires an even number of edges. Could this be improved/clarified in the docs? Thank you!
https://github.com/scipy/scipy/blob/b5d8bab88af61d61de09641243848df63380a67f/scipy/signal/_fir_filter_design.py#L942

Hi @chmendoza, thank you for reporting. Documentation improvements are always welcome.

authors: chmendoza tupui


text:
MemoryError in BinaryErosion with large arrays/kernels

See the reported issue and particularly https://github.com/scikit-image/scikit-image/issues/954#issuecomment-177239362 for the details.
From what I've succeded to track, this may be related to a direct malloc call:
1 -> 2 -> 3.

See #4878. Maybe we should change its title to some thing more descriptive.

@ewmoore looks pretty much the same.
Please, feel free to close the issue if you're considering it as a duplicate.

Duplicate of #4878.  This needs a champion.

authors: ewmoore soupault


text:
unexpected inversion in fisher_exact p-values over small range of arguments

I ran into a case of fisher_exact p-values going slowly up and then sharply down and slowly up again, over a uniform range of a single argument.  I'm fairly sure this shouldn't be happening.  Am I misusing the function somehow, or is this a real error?
>>> for x in range(1338,1356): print scipy.stats.fisher_exact([[0, x], [2369, 699722]])
...
(0.0, 0.02787009907791051)
(0.0, 0.02791103203574459)
(0.0, 0.027952350965163682)
(0.0, 0.027994055770513251)
(0.0, 0.028036146824929845)
(0.0, 0.028078624032413353)
(0.0, 0.028121487508106453)
(0.0, 0.017484170648664931)
(0.0, 0.017484101168458062)
(0.0, 0.017484299162895015)
(0.0, 0.017484764558238983)
(0.0, 0.01748549734269924)
(0.0, 0.017486497556017597)
(0.0, 0.017487765173154451)
(0.0, 0.017489300176743185)
(0.0, 0.017491102560909973)
(0.0, 0.017493172361352043)
(0.0, 0.017495509613732918)

(scipy 0.14.1, in python 2.7.10 and 3.4.3+)

I'm pretty sure that's the expected behavior.
Because of the discreteness of the sample space, exact statistics have the sawtooth patternm e.g. the power function w.r.t sample size.
The easiest would be to check with R or another package for this example.

Wow, you're right - I checked in R and got the same result. I had no idea the correct results could look so strange. Sorry about the unnecessary bug report, then.

authors: josef-pkt patena


text:
MAINT: rename moduleTNC extension back to _moduleTNC

The underscore was recently removed, see gh-14882.
This change is undesired, because it's a private namespace.

Ah, ugh:
ImportError: dynamic module does not define module export function (PyInit__moduleTNC)

Guess that was your reason to drop the underscore - when moving to Cython, the name is picked automatically based on the filename - so that filename should gain the underscore as well.


text:
DEV: Update GPG key in Docker [Gitpod]

Reference issue

No issue but I noticed this issue elsewhere
What does this implement/fix?

Recently GitHub changed the GPG signing key for the gh CLI which is installed in the Docker container.
This PR updates the key that has been causing the failures in the CI (see here for an example: https://github.com/scipy/scipy/actions/runs/3034274694)
Additional information

With the move to meson for SciPy build-related tasks, there is now a meson.Dockerfile and a Dockerfile (pre-meson) in scipy/tools/docker_dev - shall the old Dockerfile be removed to avoid confusion?

Sorted now @rgommers - also sneaked in some minor improvements to the fix permissions script to improve performance and verified locally


text:
DOC:stats: Fix levy and levy_l descriptions

Both discriptions incorrectly stated that the PDFs were valid at x == 0, which would imply that it's possible to divide by 0.

Reference issue

None
What does this implement/fix?

The documentation for the levy and levy_l distributions said that the PDF was valid at x == 0, which would imply that it was possible to divide by 0.
Additional information

The limit of the pdf as $x \rightarrow 0$ is 0, so I'm not sure that it's wrong.

I found a paper that also says x must be greater than 0: https://www.researchgate.net/publication/287520272_Some_Inferences_on_the_Levy_distribution

The limit of the pdf as x -> 0 is 0

I'm not sure that matters. Limits only say that a function approaches a value, not that it reaches it. It's like how we get derivatives by taking the limit as h -> 0, even though it wouldn't make sense to actually have h = 0.

I know, but that doesn't mean that the distribution's PDF is not defined to be zero at zero.
I'll merge this based on the citation.

authors: MatteoRaso mdhaber


text:
BUG: signal.iirfilter: avoid integer overflow

Avoid a potential integer overflow when using integer values for frequencies
Reference issue
#20455
What does this implement/fix?
The line 2*Wn/fs can cause an integer overflow when Wn is passed as (an array of) integers since it is stored as int32

CI looks happy, thanks for your first contribution to SciPy @Skylake-dev !
Any opinion on whether integer dtypes should continue to be supported or not? Does it make sense for the critical frequencies to be exact sometimes, or not? (I ask as someone with no experience in signal processing, and who hasn't looked at what impact this would have on the different output modes. If the output is always float anyway then we may as well convert to floats at the start I think, but I haven't checked whether this is the case.)

I don't really know much about signal processing myself.
Looking at the code it seems that either the Wn is already given with normalized values in [0, 1], which is a float, or it is normalized inside the function by doing the division, which also result in a float.
Since either way the result is a float i don't think that it should be necessary to convert it explicitly at the beginning and accepting integer inputs shouldn't be a problem.

authors: Skylake-dev lucascolley


text:
MAINT: sparse: Finish allowing test_base.py to easily switch between testing sparray and spmatrix

This is the third PR to tweak test_base.py so it can easily switch between testing spmatrix and sparray.
The meat of the changes are in PR #20889 (malmul tests) and PR #20894 (other tests of differing api).  This PR includes those changes. So either look only at the last commit, or wait until the others are merged.
The only tasks in this PR are:

change *_matrix to *_object, and asmatrix to asobject,
define *_object and asobject at the top based on a single line switch test_arrays = False. All tests are still performed on spmatrix. But changing this to True (locally or within a PR) runs all tests using sparray instead.

When we decide we're ready to switch to testing sparray directly (and spmatrix indirectly), another PR can change test_arrays to True to implement that change.
This PR is starting in "draft" mode because it builds on #20889 and #20894 and includes those commits. It gives a way to see the arc of those three sets of changes. It will be updated as changes are made to the other branches/PR.

The recent work in this PR creates more test classes so that all tests except Test64Bit are run on both sparray and on spmatrix. For each e.g. TestCSR there is a TestCSRMatrix test class that runs the same tests using spmatrix instead of sparray. This process revealed a couple of not-yet-released bugs that are fixed in #20894. This PR builds on that Pr and this is in Draft status until that has been merged.  Because this PR has all the changes for both PRs showing in the diff, it is probably better to look at the diff for the last two commits separately. All the rest will fall away once the other PR is merged and this is rebased.
Test64Bit is quite the beast! It manually collects all the tests for all the test classes (one for each format) and runs them all for each of about 5 versions of get_index_dtype. This configuration looks like it was in place since even before nose with the testing platform. The total time for this test class is 25.6s of the 37.3s my machine take to run the test_base.py tests.
But there is hope -- the exhaustive nature of these tests suggests it is classic technical debt. Figuring out which tests actually affect index dtype is difficult, especially when the choice of index dtype depends on the values in the input arrays. So we check every test (whether or not it uses get_index_dtype). We even test all tests for lil_matrix and dok_matrix even though they don't have an index dtype because they convert to and from formats that do. We should be able to figure out which tests are relevant and only run them.
Furthermore, sparrays treat index dtypes in a more simple way than spmatrix. In particular, sparrays do not downcast the index dtype based on the values of the indices in the input arrays. So, the number of versions of get_index_dtype we need to run is smaller than for spmatrix.
This PR sets up a switch to allow Test64Bit to run on either spmatrix or sparray. It is set to sparray by default. It passes locally for either option -- and this makes sense as the code we are testing is essentially the same for both types except that sparray doesn't check values of incoming index arrays to see if downcasting is possible.
The total time for running test_base is close to the same as before this PR. We run all the tests (except Test64Bit) twice now. But we have one fewer version of get_index_dtype to test in Test64Bit. And that cuts out one complete run of all tests (except Test64Bit).

I have (added and then) removed the test of element-wise power when the exponent is a complex number. The difficulty is that numpy changed the result of 0**(1+3j) from nan+nanj in numpy-1.24 to 0 in numpy-1.25. That is a good change for us because it means complex power operations maintain sparsity structure. But so long as we support numpy versions across that change, testing complex powers becomes difficult:

filling all implicit values/zeros with `nan
it is difficult to identify spare array values that are nan.

Indexing like A[A == np.nan] doesn't work because equality returns False for nan == <anything>.
np.isnan doesn't work directly on sparse and applying it to A.data only works for some sparse formats. We should probably make a method isnan.
np.nan is different from nan+nanj which can be constructed via np.nan + np.nan*1j

We could write the test to check the numpy version, but I haven't seen that pattern used elsewhere.  Instead I have simply postponed testing complex powers of sparse arrays until either 1) we implement something like A.isnan() or 2) scipy supports numpy>1.25.0.  If checking numpy versions is preferred that is fine with me also. Other suggestions are welcome too.

We have occasionally had tests that branched on numpy.lib.NumpyVersion but we usually try to remove them as soon as we can. It also sounds like this case would be bending over backwards, so maybe not worth indeed. I'm not a sparse regular though.

The Test64Bit tests reruns the entire collection of all other tests 5 times taking about 80% of the time for testing the sparse subpackage. Doubling that to test both sparray and spmatrix is expensive.  I have marked the sparray tests in Test64BitArray as slow, so they are not run as often. Perhaps they should be marked as xslow. Note that each test is actually fairly quick, but the parametrization leads to thousands of tests for each method in Test64BitArray and Test64BitMatrix.
I will open a separate Issue/PR to discuss marking the Test64Bit tests as slow/xslow  for sparray and spmatrix.

authors: dschult tylerjereddy


text:
DOC: Add SOS goals to roadmap

Just adding a little language about my hopes for SOS filtering as a "first-class citizen" in scipy 1.0 to the roadmap.
I've started hacking together a second order section lti class, but there's still a fair amount to be done.

D'oh. Forgot to [ci skip]. Cancelled the builds.

Soory for the noise. I'm just curious. How do you cancel a build ?

@ilayn you do it on the Travis site, but you have to have (I think) push access to the repository.

By the way, I am also writing a comprehensive control toolbox with no LTI base class ( harold ) but directly coding methods on Transfer and State classes.
Just in case you need to salvage attributes and methods it is MIT licensed. Because I don't have any user base from filtering community, I'm wondering if I can be of help with these specific representations.
From the roadmap, I see that the current lti base class is here to stay. Are there any plans to change them ? The main problem I have with this abstraction is that there are only very few items that are within the intersection of representations. Most of the crucial numerical properties for MIMO systems require extensive specialized versions say, finding zeros, frequency response computations etc. But with such inheritance you get into a lot of unnecessary sub/super class hoops.
So, if there are no options subsuming a commercial version of SLICOT, I think this would lead to a problem when things advance sufficiently complicated.
Anyways, please take this comment as a user feedback.  I don't want to start a large discussion on a PR about something else.

@ilayn you might find https://github.com/scipy/scipy/issues/6137 interesting.

@person142  Very interesting indeed.

+1 for merging this once the freqz note is fixed.

@ilayn, is your concern specifically about the weight that the current structure imposes on MIMO systems specifically?
Personally, my feelings are that scipy.signal would be well served in sticking to SISO functionality, and leave more complex applications to other libraries (such as your own!). People in diverse disciplines are interested in things like simple SISO filtering and spectral analysis, but those with very domain specific needs are perhaps better served by domain-specific libraries.

@e-q Oh OK, I misunderstood the ambitions probably. That's clear then. Thanks,
Sticking to SISO can still be quite demanding on the computation quality though, such as minimal realizations and freq grid selection etc. I think SciPy must be competent in whatever it is offering regardless of missing functionality. This type of nested inheritance will not help for future contributors in my opinion.
I guess a clearer flatter structure would make things easier for people to join on board.

In it goes then. Thanks @e-q

I think SciPy must be competent in whatever it is offering regardless of missing functionality.

definitely!

This type of nested inheritance will not help for future contributors in my opinion.

there may be a bit of an extra barrier there indeed. unraveling such design decisions from years ago is quite tricky though, need to be very careful not to break backwards compatibility. I'm not sure that it's worth the effort in this particular case.

I'm not sure that it's worth the effort in this particular case.

I agree it doesn't look very appealing. This is something that needs significant effort probably. Maybe I should say, if there will be a time that a more comprehensive functionality is needed in the roadmap, it will make the overhaul much trickier.
But I can't keep myself from commenting and adding noise. I don't know where to discuss these issues but I'm really curious about a functional roadmap such as.
The goal is to, say,
provide a signal processing framework
--> we need a) frequency domain tools --> Grid selection etc.
            b) time-domain functionalities --> ODE solvers ....
--> filter design tools, butter, filt ...

If there is a roadmap like that somewhere, I think contributors can be encouraged much easier. Currently, I'm a bit scared that I'll contribute something and that would be orthogonal to a core development idea and so on...

If there is a roadmap like that somewhere, I think contributors can be encouraged much easier. Currently, I'm a bit scared that I'll contribute something and that would be orthogonal to a core development idea and so on...

Yeah, that's exactly why we just merged a roadmap that this PR is adding something to. It can definitely be expanded to be more clear about what's in scope and out of scope. It more or less assumes now that that is understood, and focuses on what are important things to work on given that assumed scope.
It's not noise though, definitely feel free to ask or suggest new features here or on the scipy-dev mailing list.

Now that I think about it for a few more minutes and browse https://github.com/scipy/scipy/blob/master/doc/ROADMAP.rst.txt, adding a scope statement per submodule would be a really useful exercise.

adding a scope statement per submodule would be a really useful exercise.

Fully agree!


text:
BUG: Fix overflow in special.binom. Issue #8346

Changed the order of division to avoid overflow for large n, k.
1/beta(1 + n - k, 1 + k) /(n+1) -> 1/(n + 1)/beta(1 + n - k, 1 + k)

Thanks @pvanmulbregt

authors: ev-br pvanmulbregt


text:
Methods for pdf computation, parameter estimation, and variable sampling in stats.levy_stable. Support for different parameterizations.

In response to #8263.
Cross-ref #7374.

Document and support four parameterizations for the distribution, referred to as types A, B, C, and P.
Add support/fix several methods for pdf computation:

Zolotarev's: #7374 had a buggy implementation.
Quadrature integration.
Analytical expansion.
FFT + characteristic function for multiple inputs.

Support the following methods for parameter estimation:

McCulloch's quantile method
Koutrouvelis's empiricial characteristic function method.

Fix issues with random variable sampling.
Add tests for the pdf computation particularly in problematic regions of the parameter space.

Our plan is to benchmark and analyze these methods against the reference implementation/data at http://lpi.tel.uva.es/stable. We are writing an Arxiv paper to support our implementation.
Credits: this is a continuation of gh-7374 by @bsdz; most of the rest of this work was done at the Man AHL hackathon (http://ahl.com/hackathon).

Thanks for updating my original PR and improving it. It looks good and I would say it might be the most comprehensive implementation available now. Although I would disagree that the bulk of the work was done at the hackathon as my original PR was done independently with no assistance from that organisation.

cross-ref #8289 : mentioning the special cases in the docstring would be helpful here as well

The test failures here are real.

Thanks for updating my original PR and improving it. It looks good and I would say it might be the most comprehensive implementation available now.

Since the tests in this PR seem to be failing, and the ones in gh-7374 were passing, I'm not sure where we are with these two PRs. @bsdz do you think the changes on top of your PR, and if so should yours remain open? @rishabhkabra are you planning to finish this (can't tell how much work is left)?

Although I would disagree that the bulk of the work was done at the hackathon as my original PR was done independently with no assistance from that organisation.

I have edited the description at the top of the PR to more accurately reflect the history of the code here.

@rgommers Yes I noticed that this PR doesn't pass test cases. From what I see this PR should improve stability around small values of alpha although confusingly I can't see any test cases added to that effect.
The test samples I generated for pdfs and cdfs are originally from Nolan's stablec.exe program and initially I chose ranges alpha: 1.25 ->1.75 step .25, beta: -1 -. 1 step .5 and x: -10 -> 10 step 1. Nolan makes clear the limitation of his public domain executable, in particular when |alpha-1| < 0.005 or alpha=1 and beta is very small (although one could just use Cauchy here) and so I was unable to generate reasonable test samples in those ranges.
If we can get the improved alpha range support properly tested then yes the PR would be on top my PR along with the introduction of empirical parameter estimations.
I'm not sold on including the parameterisation switches preferring to perhaps offer that as a docstring or offer a link elsewhere. I don't feel it adds much to the internal calculations.
Perhaps we could merge my original PR for 1.2 with added warnings that for some very small values of alpha there might numerical stability issues and merge this PR at a later stage once it has its test cases all covered.

On Sun, 10 Jun 2018 at 17:39, Blair Azzopardi notifications@github.com
wrote:

@rgommers https://github.com/rgommers Yes I noticed that this PR
doesn't pass test cases. From what I see this PR should improve stability
around small values of alpha although confusingly I can't see any test
cases added to that effect.
The test samples I generated for pdfs and cdfs are originally from Nolan's
stablec.exe program
http://fs2.american.edu/jpnolan/www/stable/stable.html and initially I
chose ranges alpha: 1.25 ->1.75 step .25, beta: -1 -. 1 step .5 and x: -10
-> 10 step 1. Nolan makes clear the limitation of his public domain
executable, in particular when |alpha-1| < 0.005 or alpha=1 and beta is
very small (although one could just use Cauchy here) and so I was unable to
generate reasonable test samples in those ranges.

The biggest issue with Nolan paper and results is that he made error in the
scaling constant. If you read the paper carefully, especially the section
where he is manipulating complex variables, you will see the error
yourself.
I have already contacted the academic journal on this and the people in
academic community who I know can be helpful and will publish the
correction myself.

If we can get the improved alpha range support properly tested then yes
the PR would be on top my PR along with the introduction of empirical
parameter estimations.
I'm not sold on including the parameterisation switches preferring to
perhaps offer that as a docstring or offer a link elsewhere. I don't feel
it adds much to the internal calculations.

Well, I am pretty sold to doing it and it is extremely useful to have it
there. Different people in different academic papers works with different
parametrisations.
From the point of view of usability, it is pretty nice to have it there, so
that you can just directly work with parameters you have.
The goal is to make sure people learn more about stable laws and hopefully
start to use them.
Currently they are not too attracted, because there is not proper benchmark
values.
SciPy implementation has potential to exactly change this.
Why do you think SciPy should not support computations under different
parameterisations?
I think the code on stable laws is pretty long. I was wondering if we can
move to separate module and then just call in continous_dists.py

Perhaps we could merge my original PR for 1.2 with added warnings that for
some very small values of alpha there might numerical stability issues and
merge this PR at a later stage once it has its test cases all covered.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/scipy/scipy/pull/8766#issuecomment-396062917, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIfE8Vo0nogIM6xtZSQQSMgxWQ3-uwdtks5t7UvOgaJpZM4TfuV8
.

@an81, I'm struggling to see things from your perspective. In my original PR you were critical of two authors (Rachev and Mittnik) and here you are critical of another (Nolan).
In my original PR I implemented 3 distinct methods for calculating PDFs (1) FFT, (2) CF integration and (3) Zolaterev's implentation (the last being your suggestion). All 3 methods tie out with Nolan's numbers to at least 4 decimal places; the last two methods tie out to even more decimal places. It feels unlikely that so many have it wrong along with other implentations such R, matlab and more.
Perhaps you could just provide some concrete sample values of alpha, beta, x and result densities so we can see the absolute differences to those numbers I extracted from Nolan's stablec executable?

On Mon, 11 Jun 2018 at 13:32, Blair Azzopardi notifications@github.com
wrote:

@an81 https://github.com/an81, I'm struggling to see things from your
perspective. In my original PR you were critical of two authors (Rachev and
Mittnik) and here you are critical of another (Nolan).
In my original PR I implemented 3 distinct methods for calculating PDFs
(1) FFT, (2) CF integration and (3) Zolaterev's implentation (the last
being your suggestion). All 3 methods tie out with Nolan's numbers to at
least 4 decimal places; the last two methods tie out to even more decimal
places. It feels unlikely that so many have it wrong along with other
implentations such R, matlab and more.

Sure, so I think it is helpful to read the code and implementation in R and
Matlab. We were addressing exactly these issues at hackaton:
The R and Matlab implementation is pretty much wrappers around the C
library, which has taken Nolan's values as a benchmark one.
We have been in touch with the authors, yes, it will be corrected.
Just read the code and re-derive the results in the paper.

Perhaps you could just provide some concrete sample values of alpha, beta,
x and result densities so we can see the absolute differences to those
numbers I extracted from Nolan's stablec executable?

Well, I am just working on the paper which contains all this and which has
the benchmark values.
So I ll provide it on ArXiv and we add link to the documentation.
I think we had there cross-reference: how does it work with giving it a
label and adding it into milestones?
—

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/scipy/scipy/pull/8766#issuecomment-396227250, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIfE8bMfKrBxpYeRtagpt8uTPxVEnvkhks5t7mNYgaJpZM4TfuV8
.

Sure, so I think it is helpful to read the code and implementation in R and Matlab.

Eh, no. R is GPL and Matlab proprietary - if you have read their source code and then written your own code, we cannot accept that code as it then has license issues. Did you already read that code?

On Mon, 11 Jun 2018 at 17:39, Ralf Gommers notifications@github.com wrote:

Sure, so I think it is helpful to read the code and implementation in R
and Matlab.
Eh, no. R is GPL and Matlab proprietary - if you have read their source
code and then written your own code, we cannot accept that code as it then
has license issues. Did you already read that code?

Hey, why dont you have a look at this first before going into quick
conclusions: https://uvadoc.uva.es/bitstream/10324/15155/1/RoyuelaJSSoft.pdf
We have been in touch with the authors of the library and we are definitely
not reimplementing their code. The original idea was to ask them for
permission to write wrappers around their code
or let them to do it themselves, which they were definitelly keen on. But
because I have tested the numerical results coming from the code,  I know
there is error in scaling constant.
That is exactly the reason why you need different parametrisations in order
to have more robust code available.
I have been working with these distributions for over 10 years, I dont
think I need to spend time on reading matlab wrappers if thats what you
were asking.

—

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/scipy/scipy/pull/8766#issuecomment-396306832, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIfE8WIqmLoTqRkAJwIIo8FwrQReN8m6ks5t7p0_gaJpZM4TfuV8
.

Eh, no. R is GPL and Matlab proprietary - if you have read their source
code and then written your own code, we cannot accept that code as it then
has license issues. Did you already read that code?

Hey, why dont you have a look at this first before going into quick
conclusions: https://uvadoc.uva.es/bitstream/10324/15155/1/RoyuelaJSSoft.pdf

I'm not sure why I should read that article. All I'm saying is that "reading R and Matlab source code is helpful" is very poor advice; anyone who does it can no longer write code for the same functionality and have it included in SciPy.
The first R implementation that comes up is http://ugrad.stat.ubc.ca/R/library/rmutil/html/Levy.html, that package is GPL.

I have been working with these distributions for over 10 years, I dont think I need to spend time on reading matlab wrappers if thats what you were asking.

Good. At least I read that as "no I haven't read the R or Matlab source code".

I think the code on stable laws is pretty long. I was wondering if we can move to separate module and then just call in continous_dists.py

Yes, that seems like a good idea.

Perhaps we could merge my original PR for 1.2 with added warnings that for some very small values of alpha there might numerical stability issues and merge this PR at a later stage once it has its test cases all covered.

That makes sense to me.

The first R implementation that comes up is http://ugrad.stat.ubc.ca/R/library/rmutil/html/Levy.html, that package is GPL.

Update: I've now looked at http://lpi.tel.uva.es/stable and that code (C/C++/Matlab/R) is all GPL as well. It can be used to generate test data, and the provided Precomputed replication data can be used. Without written permission from the authors of that package that incorporating their code into SciPy under a BSD license, you cannot look at that source code.

Regarding the values for tests, there values seems to be correct:
https://nvlpubs.nist.gov/nistpubs/jres/77B/jresv77Bn3-4p143_A1b.pdf
They dont cover the case for alphas around 1, but there are some tabeleted values in different papers for at least 1.1 for symmetric case.

Hi @rgommers, thanks for your comments firstly. We certainly intend to finish this work. Thanks also for ensuring we can rebase on top of gh-7374.
We are aware of what is causing the tests to fail. These should be easy to fix.
More importantly, we have identified mistakes in Nolan (1997)'s method and results. This makes our changes on top of @bsdz's work rather crucial, because any implementation that uses Nolan's numbers as a reference is wrong in striking ways. We are writing an Arxiv paper to describe this because it is important for the community even beyond SciPy, and will be the basis of justifying our work here.
Our argument for supporting multiple parameterizations is two-fold: firstly, different parameterizations lend themselves to different numerical methods; these have different numerical guarantees in different regions of the parameter space. We don't want users to be stuck with one canonical parameterization. Secondly, supporting multiple parameterizations allows validation of scientific results as they as reported across different communities.
Apologies for some of the previous comments by @an81. We have not looked at any source code to be very clear (http://www.lpi.tel.uva.es/stable or http://ugrad.stat.ubc.ca/R/library/rmutil/html/Levy.html or Matlab). In the first case, @an81 was referring to the algorithms described in the accompanying paper. Thanks for advising us about the licenses.

Thanks for the context @rishabhkabra.

More importantly, we have identified mistakes in Nolan (1997)'s method and results. This makes our changes on top of @bsdz's work rather crucial, because any implementation that uses Nolan's numbers as a reference is wrong in striking ways. We are writing an Arxiv paper to describe this because it is important for the community even beyond SciPy, and will be the basis of justifying our work here.

Note that SciPy's default policy is to implement published/well-known algorithms, not novel research. However, in cases when it's clear that something is an improvement (accuracy/performance/...) then of course we will accept the novel algorithms. So in this case the ArXiV paper seems like a good idea (and I assume you'll submit it to a journal as well?).

Okay, gh-7374 is now merged. Would be great if you could rebase this PR on master.
As soon as the ArXiV paper is up, it may make sense to merge a simple doc PR that points out more possible issues and references the paper.

For what it's worth, this also doesn't fix #12658. The results here seem even less accurate than the current scipy version or #9523.
See https://github.com/scipy/scipy/issues/12658, https://github.com/scipy/scipy/pull/9523 (and maybe https://github.com/josemiotto/pylevy/issues/15 for some asymptotic expansions) for related discussions.

@steppi Another one that might be up your alley. Can you advise on whether this is worth keeping open?

@steppi Another one that might be up your alley. Can you advise on whether this is worth keeping open?

Just my 2 cents here. This PR appears to have been spurred by my previous employer after I resigned from their organisation. When I worked there, they weren't interested at all in Stable distributions (at least not when I had suggested them in my unit).
Soon after my resignation they arranged a hackathon who's only output (or mostly it appears) was a PR to compete with my own. Much of this PR was copy pasted from my original PR #7374 and initially wasn't attributed. Attribution was later added IIRC.
In their haste, it appears they might have fallen foul of license differences between Scipy's BSD and GPL. There perhaps was some value in some of their code (in particular I was hopeful for the alternative parameter estimation method). However, it might be difficult to disentangle what code is BSD compliant and what's not.

Thanks @bsdz. I'll go ahead and close it then.

I'd had started typing something here but was too busy to finish and post. Yeah, I agree, that this should be closed. Since levy_stable is in a pretty good state now, I think any parts worth mining from this should be added incrementally in small PRs, rather than one big one. The authors of this PR at least claimed that they didn't actually look at R or Matlab code, but it's good to be cautious about it. I was going to suggest opening issues for any updates we find worth mining from this so they wouldn't fall through the cracks.

authors: an81 bsdz chrisb83 mdhaber ragibson rgommers rishabhkabra steppi


text:
Making Routes For Making Dynamic NFT's For Football NFT as an example

Issue Number #39
Solving the Dynamic NFT challenges by the help of Revise SDK .
Revise offers a powerful back-end to program NFTs to interact with applications, utilities and data feeds.
I have an experience of working with Dynamic NFT's in fields of

dNFT's for Music
dNFT's for Gaming
dNFT's for Real Estate
dNFT's for Educational Certificates
dNFT's for Social Goods

@charithccmc @AbhiKul10  @mbcse  Can you provide me with some guidance so that I can write a proposal within the given time frame? Even though I know I'm running late, I'm still eager to contribute to this organization.

repo: scorelab/NFT-Toolbox


text:
[Mobile] Implemented view teams functionalilty

Description
Currently, the feature of viewing the teams present in a project is not available. This PR implements that feature.
Fixes #562
Type of change

[x] New feature (non-breaking change which adds functionality)

How Has This Been Tested?
View the details screen of a project
Test Configuration:

Realme 3 Pro
Android 10

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] My changes generate no new warnings
[x] New and existing unit tests pass locally with my changes

@UdeshUK @cazci Hello. Could you please review it? As if this gets merged, then I can also work on implementing adding/editing/deleting teams,

repo: scorelab/labellab


text:
no way to load programmatically another image after cropit is created;

I need to add the ability to rotate image after loaded, using an external button. I found a piece of code that is able to do that by creating a hidden canvas and returning png data, but when I pass it to  the cropic object (like you do in your demo page) cropit seems still keeping the old one. Also when I destroy and create again another istance not work as I expect. I think manual rotating an image is a important feature because a lot mobile devices are not managing well exif/orientation data.
And thanks for your work.

shame on me!
// Sets image source.
$imageCropper.cropit('imageSrc', 'http://placekitten.com/g/1280/800');
but after loaded the new one, it seems not refreshing how "can I move" inside the img when I'm zooming, remembering old width and height. In this specific case, I load an horizontal image (i.e. 800x200), then I rotate by 90° and reload in same cropit object. This work, but as I start zooming I notice that I can move only in horizontal direction, but now the image (200x800) need to be dragged in vertical way.

This is my snippet, take from "picademo" and from everywhere on the internet. My scope is to rotate the image, clicking on .cropit-turn, by 90°.
Notice that BEFORE and AFTER rotation (working) the width and tje height are the same.
var $editor = $('.image-editor');
$editor.cropit({smallImage:'allow',width:250,height:250,exportZoom:1.2,initialZoom:'min'});
$('.cropit-turn').click(function() {
console.log("IMG PRE:"+$editor.cropit('imageSize').width+" y:"+$editor.cropit('imageSize').height);
		var imgSrc = $editor.cropit('imageSrc');
		var img = new Image();
		img.src = imgSrc;
		var originalWidth = $editor.cropit('imageSize').width;
		var originalHeight = $editor.cropit('imageSize').height;

        // ROTATE
        var degrees=90;
        var rads=degrees*Math.PI/180;
        var newWidth, newHeight;
        var c = Math.cos(rads);
        var s = Math.sin(rads);
        if (s < 0) { s = -s; }
        if (c < 0) { c = -c; }
        newWidth = originalWidth * s + originalWidth * c;
        newHeight = originalHeight * c + originalHeight * s;
        var canvas = document.createElement('canvas');
        var ctx = canvas.getContext("2d");
        canvas.width = parseInt(newWidth, 10);
        canvas.height = parseInt(newHeight, 10);
        var cx=canvas.width/2;
        var cy=canvas.height/2;
        ctx.clearRect(0, 0, canvas.width, canvas.height);
        ctx.translate(cx, cy);
        ctx.rotate(rads);
        ctx.drawImage(img, -originalWidth / 2, -originalHeight / 2);

        var picaImageData = canvas.toDataURL();

		$editor.cropit('imageSrc', picaImageData);
        console.log("IMG AFTER:"+$editor.cropit('imageSize').width+" y:"+$editor.cropit('imageSize').height);
    });

repo: scottcheng/cropit


text:
Small images (~ 50KB and under) are not being loaded

Noticed this when updating from v0.2.0.  The problem seems to have been introduced between v0.2.0 and v0.3.0.  You can also verify this by attempting an upload on the demo page (current version is 0.4.1).

Here's a demo image (but any jpeg of small filesize can be used).

Hi, I'm made some test on the Demo Page and in fact for me isn't a problem with filesize but with the image size. If you try with the first sample in the demo page : the DIV have dim : width: 448px; height: 448px. If we try to upload an image smaller than 448px it's not loaded, we have to use a bigger image than 448px.
Try with these images the first one 447px (doesn't work) and the second 449px (works for me)

I'll will learn if it's possible to detect a too smaller image with event.

my bad.  I had a closer look and it seems there is a smallImage option which is set to 'reject' by default (see documentation).  Setting it to 'stretch' solved the issue for me.  I'm guessing this option didn't exist for version 0.2.0.
Closing issue...

Maybe it's a good idea to modify the demo page. Because when I've tried the first time I believe that the library doesn't work with png (in fact I've used a too smaller image).

...or imho have smallImage set to allow or stretch in the library by default.

authors: CyrilSiman tgiunipero